[asterisk-dev] Asterisk 1.6 Release Management Proposal
Russell Bryant
russell at digium.com
Wed Oct 17 12:53:00 CDT 2007
Greetings,
A few weeks ago, I proposed to this list that we create a new release series
that is managed with a short release cycle to introduce smaller sets of new
features. I also wanted to increase the emphasis that we put on testing new
sets of functionality for potential regressions.
The feedback on this list was positive, as was all of the feedback I have
received directly. I spoke to people about this a lot at Astricon, and received
no negative feedback.
So, I would like to move ahead with formalizing this new release series,
Asterisk 1.6. I have documented the new release policy that will apply to this
release series, as well as some of the history that inspired these changes to
release management.
I have included the document and would appreciate any feedback from the
development community.
In short, as long as there are no significant disagreements, I plan to create an
Asterisk 1.6.0-beta1 snapshot next week. I will continue to make beta tarballs
until we are comfortable moving to release candidate status. I will then create
an Asterisk 1.6.0 branch and start making release candidate snapshots, named
1.6.0-rc1, etc. After a reasonable amount of testing and no known regressions
introduced by the new changes in 1.6, I will release 1.6.0. The 1.6 release
series will continue to be managed in the manner described in the included
document.
The current levels of maintenance of Asterisk 1.2 and 1.4 will not change at any
point in the near future.
Let me know if you have any questions, comments, or concerns.
Thanks,
---------------------------------------------------------------------------
Asterisk 1.6 Release Management
Russell Bryant
Digium, Inc.
October 17, 2007
Contents
1 Introduction 1
2 Current Problems 2
2.1 CVS Head, 1.0, 1.2, 1.4 ... . . . . . . . . . . . . . . . . . . . . 2
2.2 Shot in the Foot . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3 Changes for Asterisk 1.6 2
3.1 SVN Branch Layout . . . . . . . . . . . . . . . . . . . . . . . 3
3.1.1 team branches . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.2 trunk . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.3 tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.4 branches/1.6.X . . . . . . . . . . . . . . . . . . . . . . 4
3.2 SVN Commit Workflow . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1 Small new feature . . . . . . . . . . . . . . . . . . . . . 5
3.2.2 Significant New Feature . . . . . . . . . . . . . . . . . 5
3.2.3 Small Bug Fix . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.4 Invasive Bug Fix . . . . . . . . . . . . . . . . . . . . . 5
3.2.5 Security Fix . . . . . . . . . . . . . . . . . . . . . . . . 6
1 Introduction
This document describes the release management strategy for Asterisk 1.6.
It is vastly different than what has been done for previous releases, so having
a clear understanding and agreement on how it will be done is critical.
1
2 Current Problems
Before diving into how Asterisk 1.6 will be managed, it is worth reviewing
the release history that has inspired these changes.
2.1 CVS Head, 1.0, 1.2, 1.4 ...
Just a few years ago, everyone that was using Asterisk obtained it by checking
out the latest code from the development tree, which was CVS Head. This
meant that Asterisk was a very fast moving target, and users just hoped that
they caught it on a good day.
In the Fall of 2004, Asterisk 1.0 was released. This began the era of
managed releases of Asterisk. The policies established at this point carried
on into 1.2, and then 1.4. The simple policy for release branches was ”only
bug fixes”. The idea is that if you keep code changes to an absolute minimum,
then there is a smaller chance of new bugs getting introduced.
Well, great news! The release management for the past few years has
been a success, to some degree. Releases have proven to get very stable and
the entire Asterisk user community has transitioned to using the releases.
2.2 Shot in the Foot
The problem with this release management comes up when we want to release
a new version. Over a few years, we have gone from everyone running the
latest development code, to only a core set of developers using it. So, bugs
aren’t being discovered during development, and only show up when it gets
into a release.
When the release is made, we are stuck tracking down weird bugs intro-
duced during a year to a year and a half’s worth of development. This is not
fun for anyone. This is the exact reason it has taken so long for Asterisk 1.4
to really get stable.
3 Changes for Asterisk 1.6
Asterisk 1.6 introduces a new release management style for the Asterisk
project.
2
The 1.6 version will receive new functionality in smaller increments. In-
stead of doing doing another year of development before releasing an ex-
tremely large set of changes as Asterisk 1.8, we will be adding things into
each release of 1.6.
While trunk continues to receive new features and architectural improve-
ments, we will make 1.6.X release branches every month or two. After the
branch is made, we will make release candidates available while the devel-
opment team and community members test for regressions introduced by
what new things have been introduced in this release. The timeframe stated
here is intentionally vague because releases will be determined based on code
quality, and not an arbitrary date.
Meanwhile, while a 1.6.X release branch is being tested, new things can
continue to be merged into trunk. After an official 1.6.X release is made, a
new 1.6.X release branch will get created and the process will start over.
3.1 SVN Branch Layout
• asterisk/trunk
• asterisk/team
– asterisk/team/russell
– asterisk/team/kpfleming
– asterisk/team/file
∗ asterisk/team/file/cool-branch1
∗ asterisk/team/file/cool-branch2
• asterisk/tags
– asterisk/tags/1.4.11
– asterisk/tags/1.4.12
– asterisk/tags/1.6.0-rc1
– asterisk/tags/1.6.0-rc2
– asterisk/tags/1.6.0
– asterisk/tags/1.6.0.1
– asterisk/tags/1.6.0.2
3
• asterisk/branches
– asterisk/branches/1.2
– asterisk/branches/1.4
– asterisk/branches/1.6.0
– asterisk/branches/1.6.1
– asterisk/branches/1.6.2
3.1.1 team branches
For anyone with commit access, this is where large all new developments
should go first. This includes any significant new features or invasive bug
fixes that need extra testing. The changes should not move into release
branches until they are reasonably tested and considered ready for release.
3.1.2 trunk
This is where all of the new developments go once they are considered ready
for release. 1.6 sub-releases will be branched off of trunk every month or two.
Special care must be taken by those with commit access to not introduce a
large number of extremely invasive changes to the same parts of the code
in the same 1.6 release cycle, as we want to make tracking down regressions
from invasive changes as easy as possible.
3.1.3 tags
Tags are simply release snapshots. A tag is made every time that a tarball
is created and reflects exactly what was in the release.
3.1.4 branches/1.6.X
1.6 branches will be created every month or two. They will include all of the
new functionality committed to trunk since the previous 1.6.X branch. After
the branch is created, release candidates will be previously tagged off of the
branch while testing is being done. After a reasonable amount of testing has
been done and the development team is comfortable that none of the new
things introduced in the release have caused any regressions to the best of
their knowledge, then the official 1.6.X release can be made.
4
If any significant regressions are found after the 1.6.X release, then com-
mits can be made to the 1.6.X branch to fix the issue, and 1.6.X.X releases
can be made.
3.2 SVN Commit Workflow
3.2.1 Small new feature
Commit directly to trunk.
3.2.2 Significant New Feature
Commit to a team branch. Once the feature has received a reasonable amount
of testing, then it can be committed to trunk, as long as it does not conflict
with other significant changes made to the same code in the current 1.6
release cycle. If that is the case, then the commit of this significant change
should wait until the next release cycle.
Contact Russell Bryant or Kevin Fleming for help in deciding, if necessary.
3.2.3 Small Bug Fix
1. Commit to the 1.4 branch
2. Commit to the current 1.6.X branch that is in testing, but only if the
bug is a regression introduced in that specific 1.6.X release. If it is a
bug that has been around longer than that, it will have to wait until
the next 1.6.X release.
3. Commit to trunk
3.2.4 Invasive Bug Fix
Commit to a team branch. Once the patch has received a reasonable amount
of testing, then it can be committed to the 1.4 branch and trunk, as long
as it does not conflict with other significant changes made to the same code
in the current 1.6 release cycle. If that is the case, then the commit of this
significant change should wait until the next release cycle. Also, if the fix
is for an issue that was introduced in the current 1.6.X branch that is in
testing, then the fix may be put there.
Contact Russell Bryant or Kevin Fleming for help in deciding, if necessary.
5
3.2.5 Security Fix
1. Commit to the 1.2 branch
2. Commit to the 1.4 branch
3. Commit to the current 1.6.X branch that is in testing, as well as the
past three 1.6.X release branches so that sub releases of those can be
made that include the fix.
• Note that the number three here is arbitrary. It may change based
on what community members would like to see.
4. Commit to trunk.
6
--
Russell Bryant
Senior Software Engineer
Open Source Team Lead
Digium, Inc.
More information about the asterisk-dev
mailing list