Asterisk Developers Mailing List: [policy] Merging between branches
Huge thanks to Joshua Colp for mirroring services
| Greetings,
Last year, when we first started discussing Asterisk 1.6 branch policy, 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,
--
Russell Bryant
Senior Software Engineer
Open Source Team Lead
Digium, Inc. |
| | Original Content (C) 2004-2009
Matt Riddell |
|
 | |
|