[asterisk-dev] Tension between trunk and release branches

Tzafrir Cohen tzafrir.cohen at xorcom.com
Thu May 31 13:36:02 MST 2007


On Thu, May 31, 2007 at 04:28:07PM +0000, Tony Mountifield 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:
> 
> 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.

In that case there will usually also be a patch vs. th production branch
in the mantis. There should be, because that is the patch most tested in
the field.

Sadly, the Asterisk "stable" branches are moving targets of their own,
and often patches for older versions of the stable branch will break
with newer versions.

This indicates, IMHO that there is actually too much "development" done in
the stable branches already. As an indication to that, it is not
considered safe enough to upgrade for 1.2.x to 1.2.x+n without proper
testing. 

> 
> 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.
> 
> d) How can the above points be addressed? 

Shorten the release cycle. This is the only proper way to get newer
features in faster. 

There are some potential downsides to that, mostly because it may take
more testing resources.

> 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. 

Right. It seems indeed that potential testers are discoureged from using
trunk, as it "doesn't really work". At least this has been the case 
for much of the 1.4 release cycle (before the freeze, that is).

So can trunk now be good enough for a server that should generally not
break? Think of the server for the developemnt conference calls: we'll
probably be tollerant to a few issues here and there, and would be
interested in looking at them, but will generlly like that server to
work.

> (Yes, I know that team branches are used nowadays
> for many initial developments before they are ready for trunk).

Anybody actually testing code from development branches (without Olle
pointing a gun to his head?)

-- 
               Tzafrir Cohen       
icq#16849755                    jabber:tzafrir at jabber.org
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com       
http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir


More information about the asterisk-dev mailing list