[asterisk-dev] Thoughts on Asterisk release management

[Russell Bryant]

Stephen Davies wrote:
> So I'm one of the foolish and brave who have been running SVN Trunk on
> a production system.

It has been much appreciated.  :)

> I must say that I tried to update my live service box last Tuesday to
> trunk rev 81432 - with your new astobj2 stuff in chan_iax2.  I don't
> know if I messed up the upgrade, but it just crashed and crashed and I
> had to revert.  This is despite it running well on my other
> "semi-production" box.
> 
> So I haven't had a chance or courage to try it again.  So this sort of
> process runs slowly.

Well, that is certainly not good.  The code has been sitting in the 1.4 branch
for a while now and I haven't heard any complaints.  I hope that it is working
for people and it's not that nobody is using it.

If you are ever able to replicate the problems and have the time to gather debug
output, I would be more than happy to look into it and get it fixed.

> The other thing I'm aware of is that changes go into SVN trunk and by
> the time they get into releases that people will use, the details have
> been long forgotten.  For instance, who is aware that Set()
> application has been changed to no longer accept more than one
> var=value.  This will break dialplans in a Mysterious way.
> Set(a=b,c=d) in SVN trunk will set a to "b,c=d".  In 1.2, 1.4 is sets
> a to "b" and c to "d".

We certainly try not to "forget" the changes like this by documenting them in
UPGRADE.txt.  If you ever come across something like this that isn't documented,
please point it out (and I know you already have been) so that it can get done.

> Anyway - anything that makes it easier and a bit safer to try the new
> code is welcome!
> With your proposed model I can try out those "beta"s.
> 
> By the way - for me it would be much easier to simply pull the SVN at
> the time rather than download a package.  That way my local changes
> tag along easily, and I can make and provide patches easily.

Running straight from trunk is fine.  The motivation for making tarballs is just
to make it easier for a larger audience to test the code.  The real work is
streamlining how and changes make it into trunk.

> I'm conscious that the developer branches are also "ghettoizing"
> changes so they aren't getting tested.  So maybe those branches should
> be trying to get their changes over into the main trunk in a similar
> cycle?

Absolutely.  Developer branches are just a much better way of writing code than
having it sitting in a working copy on your local hard drive.  I would like the
merge window to be when we take the pending developer branches that are ready
for public consumption and pull them into trunk.

Of course, depending on what is pending, some may need to get deferred to the
next cycle to avoid having too many extremely invasive changes at once.

-- 
Russell Bryant
Software Engineer
Digium, Inc.