[asterisk-dev] Tension between trunk and release branches

[Dan Austin]

Tony wrote:

> As I mentioned in my thread about a proposed new 
> Meetme feature, there is an interesting tension 
> between release branches and trunk, which I don't
> think has ever been adequately addressed:

This is mostly a 'me too' response
> a) People running production systems will naturally 
> want to run a release branch, not the trunk. Trunk 
> is used to test out new features, changes to 
> architecture, etc., and is fine for "pure" developers,
> e.g. those at Digium whose job it is just to work on 
> new features for the general enhancement of Asterisk.

> b) Most people deploying Asterisk in the field develop
>  new features because they have a customer need to run
> that feature in a production system. Therefore they
> develop it for themselves on a release branch, such as
> 1.2 or 1.4. This is certainly what I do.

> c) On submitting such a feature to Mantis, it only ever
> gets accepted into trunk, and so the originator has to
> "forward-port" it to trunk, and also keep maintining his
> own backport until such time as trunk becomes a new 
> release branch. It then still takes a long time until 
> the release branch is bug-free enough to run in 
> production systems.

If you can even get it looked at...

> d) How can the above points be addressed? It seems we need
> a mechanism to add non-invasive extra features to a 
> production-quality branch after they have been sufficiently
> tested. By "non-invasive", I mean features that are 
> effectively just clean additions without making 
> architectural changes to Asterisk as a whole. All the 
> dangerous completely-break-it-then-fix-it changes would 
> still be done in the "experimental" trunk. (Yes, I know
> that team branches are used nowadays for many initial
> developments before they are ready for trunk).

Not sure.  The whole concept of "non-invasive" is hard to
quantify.  The recent DTMF rework was needed and valid.
On the surface it even appeared relatively non-invasive.
But it broke chan_skinny, and the channel has remained
broken for two 1.4 releases.  The issue was truly a problem
with how the channel collects digits to place a call and
the proper fix was to change how the channel performed that
function.  The resulting change is not "non-invasive", yet
I am not sure there is a better way to repair the channel.
I coded the fix against branches/1.4, and another user
ported it to Trunk.  Both need it, but which should get it
first....


> Thoughts?
Sadly I think it would require a team of capable developers
to spend time evaluating the "invasive-ness" of each change.
I say sadly, as their time would likely be better spent coding.

Dan