[asterisk-dev] Thoughts on Asterisk release management

[Russell Bryant]

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

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.

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.

-- 
Russell Bryant
Software Engineer
Digium, Inc.