[asterisk-dev] Asterisk 1.6 Release Management Proposal
Alvaro Parres
aparres at gmail.com
Wed Oct 17 14:16:53 CDT 2007
It reads very good...
Russell Bryant escribió:
> 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
>
>
>
More information about the asterisk-dev
mailing list