Asterisk 1.6 progress

1.6 seems to have been on Beta9 for a loooong time. Anyone have any inside info on how things are progressing? Don't recall a release being stalled as long as this one.
Or are the developers really working hard on making it as perfect as can be?

regards

There was changes to the release cycle with 1.6 laid out when it was started. The Dev blogs do show a lot of work going on.

see below

Quote:

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.

Thanks for that, I have to agree with some of the sentiments. 1.4 releases have been patchy to say the least.

Basic functionality seems to get broken all to frequently.

For me, gone are the days of running the lastest release. It's simply too risky. Guess it's (the code) simply getting to complex at times.

My only real gripe with the new development is the insistance on changing the CLI commands to a new format, for no apparent gain, i.e. why must I prefix commands with 'core'. Wish they had addopted Cisco thinking, in that if it wasn't ambiguous accept it.

Still doesn't explain why beta9 has been around months though.

regards