On 07.08.2012 13:09, [email protected] wrote:
> While the two setups are very similar, almost isomorphs, they're not exactly > so. There are important practical consequences that distinguish the two. > > - Releases happen on a fixed schedule > - Minor versions have a defined lifetime > - The number of patch releases is limited by default. > > These give predictability and focus to everyone participating on the project. > It gives everyone something to align to. I understand the advantages of these points and fully support them. I just wonder, why you need the parallel rolling branches for it. Can't we just establish the fixed scheduling in the classical branches? Instead of fixed merge-down-days we would have fixed branch-days. > There are other practical consequences. As a developer, you don't have to > worry about *when* to do or merge a specific change. You get it up to snuff > and decide *where* to apply it (i.e., on which branch). > > The fact that the branches roll from release to release means anyone tracking > development branches decides how much pain they are willing to take and stay > the course. You don't have to wait for the next branch to come along so you > can jump to it. Ok, here I see the point. Tracking a certain level of code quality is easier with rolling branches. OTOH it's probably easy to install automatic commit-aliases that track which ever branch currently has a specific quality status, like "beta" or "rc". > "Quality" in a way jumps up and down with the merges, but I don't think we > can eliminate these jumps at the moment and in reality they are not > introduced by the proposed model. Of course we can't eliminate the quality changes. That's why I asked if we shouldn't better use a model, that makes that fact explicit (transition focused rather than level focused) by branches that (more or less monotonically) increase in quality until end of life (alpha->beta->release->security-fixes). That would at least eliminate the jumps. Sven _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
