Hi, On 07.08.2012 01:12, Thiago Macieira wrote: > On terça-feira, 7 de agosto de 2012 01.00.54, Olivier Goffart wrote: >> ---+--------------------------+---------------------- fire-hose >> / \ / / / / / / / / \ / / / / / / >> --+ +-----+--------+--------+ +-----+--------+---- leaky-faucet >> / \ / / / \ / / / \ / / / \ / / / \ / / / \ >> -+ +-----+ +-----+ +-----+ +-----+ +-----+ +- dripping-bucket >> \ \ \ \ \ \ >> 5.0.1 5.0.2 5.1.0 5.1.1 5.1.2 5.2.0 > > I think you're missing the dashes between 5.0.1 and 5.0.2. > > dripping-bucket is a rolling branch. To make it fast-forward from one release > to the next, it needs to merge them.
What exactly is the advantage of having "rolling branches" for the different stability levels compared to the "specialized" branches for each level of version number. Wouldn't it have the same effect but clearer semantics if you have a single rolling branch which maintains something like alpha level quality, and from that you create a 5.X branch that _targets_ beta quality, and after it reached it you start creating 5.X.Y branches that target release quality. 5.X+1 is created, when the last 5.X.Y has been created and 5.X therefore is dead. This way you also have exactly 3 active branches at each time and should be isomorph to the solution with three continuously rolling branches, but easier to understand in my eyes. This might sound more complicated on the first view, but note that also leaky-faucet and dripping-bucket would have different quality states right after the down-merges until it stabilizes to the targeted quality level. This change in quality of the branches is not very transparent from the model, which incorrectly suggests that each rolling branch has a constant quality level. That's why I would go for specialized branches which more obviously traverse different levels of quality. Or more generalized: I would prefer a model, that focuses on quality _transitions_ rather than quality _levels_, because that's what it's all about, right? But maybe I'm missing an important aspect. Sven ________________________________ * Join our Partner program: http://www.snom.com/partner<http://www.snom.com/partners> * Subscribe to our snom support RSS Feed<http://wiki.snom.com/wiki/index.php?title=RSS&action=feed&feed=rss> and get first-hand technical news about snom products, e.g. Firmware updates, FAQ updates, troubleshooting hints, etc. Follow us on Facebook<http://www.facebook.com/snom.VoIP.phones>, Twitter<http://twitter.com/snom>, YouTube<http://www.youtube.com/user/snomvoip>, Linkedin<http://www.linkedin.com/groups?gid=1773766> Sitz/Domicile: Charlottenstr. 68-71, 10117 Berlin, Germany Handelsregistereintrag/Register of Corporations entry: Berlin-Charlottenburg HRB 61842 B Vorstand/Executive Board: Dr. Michael Knieling, Usman Tahir, Alexander Khan Vorsitzender des Aufsichtsrates/Chairman of the Supervisory Board: Stefan Friese snom technology AG<http://www.snom.com> _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
