[asterisk-dev] [policy] Merging between branches

[Russell Bryant]

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.

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.

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.

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

-- 
Russell Bryant
Senior Software Engineer
Open Source Team Lead
Digium, Inc.