[Development] Setting up time-based releases for the project

Sven Anderson Sven.Anderson at snom.com
Tue Aug 7 16:08:16 CEST 2012



On 07.08.2012 13:09, joao.abecasis at nokia.com 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



More information about the Development mailing list