Russell has posted an extensive document on the release management proposal for Asterisk 1.6:

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
2 Current Problems
 2.1 CVS Head, 1.0, 1.2, 1.4
 2.2 Shot in the Foot
3 Changes for Asterisk 1.6
 3.1 SVN Branch Layout
  3.1.1 team branches
  3.1.2 trunk
  3.1.3 tags
  3.1.4 branches/1.6.X
 3.2 SVN Commit Workflow
  3.2.1 Small new feature
  3.2.2 Significant New Feature
  3.2.3 Small Bug Fix
  3.2.4 Invasive Bug Fix
  3.2.5 Security Fix

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.

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

The 1.6 version will receive new functionality in smaller increments. Instead of doing doing another year of development before releasing an extremely 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 improvements, 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 development 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

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

If any significant regressions are found after the 1.6.X release, then commits 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.

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.

--
Russell Bryant
Senior Software Engineer
Open Source Team Lead
Digium, Inc.

Comments (Click to post)

Name:
Subject:
Website:
Message: