[asterisk-dev] [policy] Merging between branches

[Mark Michelson]

Russell Bryant wrote:
> Greetings,
> 
> Last year, when we first started discussing Asterisk 1.6 branch policy 
> [1], we had said that the only time that we would change a 1.6.X branch 
> after it had reached a release state is for regressions against a 
> previous release.
> 
> What that has meant in practice is that as we find and fix long standing 
> bugs that apply to all of our releases, 1.6.0 does not receive the fix. 
>   Currently, that means a fix would go into 1.4, trunk, and then 1.6.1 
> since it is still in beta.
> 
> I now believe that this was a mistake.  As it stands today, upgrading 
> from 1.4 to 1.6.0 will introduce a number of regressions for users. 
> This should never happen (until 1.4 or 1.6.0 is no longer in a supported 
> state).  So, I would like to immediately change the policy such that 
> every fix that applies to 1.4 should also go into _every_ supported 
> 1.6.X branch.

A hardy +1 from me. I have, however, mostly been following the policy of not 
merging 1.4 bugfixes into 1.6.0 since they were not regressions in the 1.6.0 
branch. I say mostly because in some cases the bugs were grievous enough that I 
could not in good conscience exclude the change from 1.6.0 (think crash or 
deadlock bugs).

> 
> We had a discussion about this last week on IRC.  It seemed that 
> everyone around at the time was in agreement about the change as far as 
> normal bug fixes go.  However, there was some debate about what the 
> policy should be as far as new features in 1.6.X go.
> 
> In my opinion, any type of bug in a supported 1.6.X branch is a 
> candidate for being fixed.  Nothing should be excluded from that.

I agree with this given the slow pace of 1.6.X releases and the fact that moving 
from 1.6.X to 1.6.X+1 introduces potentially unwanted new features and with 
those, potential new bugs.

> 
> There were some that were in favor of restricting this to reduce 
> development workload.  What I would like to do is leave the policy such 
> that all bugs in supported releases should be fixed.  However, if there 
> is a special case where the differences between 1.6.X branches are so 
> great in a certain area that applying a fix to multiple releases becomes 
> unreasonable, then we can treat it as a special case and potentially 
> exclude the fix from older releases, as appropriate.  This should be a 
> _very_ rare case.  I would prefer that Kevin or I review it before such 
> a decision is made.
> 
> Comments are welcome.  Feel free to use specific examples.  However, 
> when suggesting changes, please also indicate how you would change the 
> generic policy to accommodate the example situation.
> 

I mentioned above the slow process that has happened so far with the 1.6.X 
releases. 1.6.0 was released on 2 October. It is now 1 December and there has 
been only one beta of 1.6.1 made so far. Since it must continue through the beta 
cycle and also go through an rc process, I don't see 1.6.1 being released before 
the end of the year. The original plan for the 1.6 series called for releases 
approximately every month. If this were followed, then the number of new 
features in each subsequent release would be more limited. By doing this, moving 
from one release of 1.6.X to the next in the series would not involve as much 
risk. This could mean faster adoption of new releases and consequently ending 
support for older releases in a more rapid fashion. This would also hopefully 
eliminate some of the larger differences between the various 1.6.X branches, 
which would make the development effort of maintaining multiple releases easier.

The longer release cycle isn't necessarily a bad thing either. It just requires 
that major new features and refactorings need to be introduced into trunk in a 
slower, more controlled process. For instance, right now if a new feature is 
deemed ready (meaning that the code has been reviewed and the feature has been 
tested), the typical course of action is to immediately merge the new feature 
into trunk. The problem with this is that new features can build up if a new 
release takes a long time to come to fruition. If we are to have long release 
cycles, a method of gradually introducing new features into trunk needs to be 
implemented, hopefully without the fear of bitrot occurring in developer 
branches. Unfortunately, I don't have any real good ideas off the top of my head 
for a graceful way to do this.

> Finally, I plan to take this opportunity to formally document our 
> release and branch management policies after this discussion.  I'll get 
> it in a document in the source tree as well as on asterisk.org.
> 
> Thanks,
> 
> [1] http://lists.digium.com/pipermail/asterisk-dev/2007-October/030083.html
>