[asterisk-dev] Thoughts on Asterisk release management

[Tzafrir Cohen]

On Wed, Sep 19, 2007 at 06:24:35PM -0500, Russell Bryant wrote:
> Greetings,
> 
> The process of developing, releasing, and maintaining Asterisk 1.4 has certainly
> been a learning experience.  I have been putting a lot of thought into the
> things that we have been dealing with and would like to propose some changes to
> the way that we manage releases.
> 
> 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.
> 
> The problem is that now that nobody is using the development code, it goes
> through a year of major changes without enough usage.  So, the number of bugs
> introduced increases and becomes overwhelming when they eventually come around.
>  The process of making Asterisk 1.4 usable by everyone has been extremely
> painful.  I think it has been more painful than the transition to 1.2 because a
> lot more people were running the development tree before 1.2 was released than
> was the case with 1.4.
> 
> So, I would like to propose a change to our release management to reduce how
> much time code sits without being put to use.
> 
> Here is what we have now:
> 
>     1.2 - The deprecated release branch updated for security issues.
>     1.4 - A feature frozen release branch that is fully supported and receives
>           any type of bug fixes, but not new features.

Theoretically it is feature frozen. But in practice I hear too many
reports of behaviour changes between minor versions. Hence an upgrade
there might be risky as well.

>     trunk - Development land.  All changes are fair game.
> 
> I don't want to create any new branches.  What I would like to do is put some
> more structure into how we manage trunk.  Specifically, here is what I am thinking.
> 

>     1) If and when this plan is agreed upon, immediately tag trunk and release a
> 
>        1.5.0-beta1.  Feature freeze trunk for about a month.  In this month,
>        encourage people to test what we have.  Fix things as we find them and
>        eventually release 1.5.0.  Re-open trunk for full development.
> 
>     2) Stick to a slightly more structured way of handling development in trunk.
>        Instead of it being a free-for-all all of the time, have merge windows
>        and short feature freezes so that we can make incremental releases.  I am
>        thinking a 6-week release cycle: 1 month open merge window, a release
>        candidate, 2 week feature freeze, test, release, repeat.  We must use
>        discipline in how we manage trunk development, or else nobody would run
>        the releases.
> 
>        Then, eventually, 1.2 would be officially deprecated, 1.4 would move to
>        security maintenance, 1.5 would become 1.6, and we would continue making
>        incremental releases with new features labeled as 1.7 ...

This is surely great for development. The problem is: is this good for
users who don't have the latest and greatest anymore?

> 
> I have a couple of final notes about this.  First, I really don't think this
> should hinder development in any way.  A lot of work has gone into making it
> very easy to maintain code in developer branches, so it shouldn't be a big
> problem to put off merging major code changes for the short feature freeze periods.
> 
> Second, even within the open merge window for trunk, we would still need to be
> smart about when major changes get merged.  For example, we should try to spread
> out the most invasive changes into different release cycles as much as possible,
>  to make tracking down regressions as easy as we can.
> 
> I think if we could get some community buy in on this, we will be dealing with
> much fewer new bugs at a time, which will make Asterisk a lot more stable in the
> end.  I really don't want to deal with building up a year to a year and a half
> of changes before people actually start using them ever again.

Quick poll, for Linux users: what kernel version does your Asterisk
server run on? No distro OS bashings, please. I' do have a point in
this.

My laptop is 2.6.22-1-686 from Debian, my two desktops are
2.6.18-5-{686,amd64} . I have one server with self-built 2.6.22.6 , but
I decided to use a self-built kernel there only after major issues with
the distro kernel (and wasted tons of time in the effort).

The point is: this tries to mimmic the success of the faster development
of Kernel 2.6. But with Kernel 2.6 there is a huge QA buffer between the
developers and the end users. s a result, servers have very diverse
kernel versions and upgrading to the latest to get a new feature is
sometimes not an option.

I'm not saying that this is a bad idea. Just saying that when we get to
1.9 , we'll still get bug reports from people running 1.5 . And asking
them to test with 1.9 wouldn't be a realistic option.

> 
> What do you think?  Does this sound like a good idea?  Would people buy in to
> this and actually use the 1.5 releases?  If not, I am very interested to hear
> any other ideas people have that may improve the way we manage releases.  Feel
> free to point out other large open source projects that have release management
> that you find especially successful.

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