[asterisk-dev] Thoughts on Asterisk release management

[Stephen Davies]

On 20/09/2007, Russell Bryant <russell at digium.com> wrote:
> Over the past few years we have gone from not having managed releases, to
> Asterisk 1.0, 1.2, and now 1.4.  Over this time period we have transitioned from
> everyone using the development code directly to now nobody using the development
> code for any real purpose.  This has both been a great thing and a curse at the
> same time, as I have come to realize.


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

I started doing so when we started trying to move 1.2 to security problems only.

I knew that there were issues in 1.4's IAX having tried to use it and
failing.  But nobody had had the courage to suffer the seg faults and
find the problems.

I know also that 95% of my customers in South Africa were still using 1.2.

Luckily Mihai et al had the same thoughts and have also been working
to fix 1.4/trunks chan_iax.  And most of the fixes came from them.
And I think that this effort has made a big diference to recent 1.4s.

So it doesn't need a lot of people to test the code - it just needs
some stubborn and experienced people who will chase down the issues.

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.

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

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.

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?

Regards,
Steve