[asterisk-dev] Asterisk 1.6 Release Management Proposal
BJ Weschke
bweschke at gmail.com
Thu Oct 18 11:52:39 CDT 2007
3.2.1 Small new feature
Commit directly to trunk.
------------------
Russell,
First off, thanks for taking the time to put together a document
and try to start getting a handle around what is obviously become a
more mature software solution that more and more businesses are
accepting for their mission critical communications. I really think
this effort is absolutely necessary as the community of Asterisk
matures along with its work product.
However, with the respect to the above statement, I don't think I
agree with this mentality. This seems to go against any concept of any
kind of SDLC and seems to contradict other parts of the document.
While I agree that it is what has been standard practice in the past,
I read this document (and maybe I misread it) that we're making an
attempt now to make trunk more of a "golden" copy of all things
accepted vs. the "playground/sandbox/litter box <-- take your pick of
WHAT you want to call it. :) " it is now. If that's the case, and I
agree with the cause there, then anything and everything I think
should go through some sort of review/consideration before making its
way into trunk.
Also, that all being said, if this is how we want to treat trunk
going forward, what migration process will be defined for moving trunk
from what we've all accepted it to be now (pick your favorite word for
it up above) and get it to where we want it to be?
BJ
On 10/17/07, Russell Bryant <russell at digium.com> wrote:
>
> 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.
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-dev
--
Bird's The Word Technologies, Inc.
http://www.btwtech.com/
More information about the asterisk-dev
mailing list