I have published a document describing the details of the release management for Asterisk 1.6. See the full post to the mailing list here.
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.
The process of developing, releasing, and maintaining Asterisk 1.4 has certainly been a learning experience. I have been putting a lot of thought into the things that we have been dealing with and would like to propose some changes to the way that we manage releases.
Over the past few years we have gone from not having managed releases, to Asterisk 1.0, 1.2, and now 1.4. Over this time period we have transitioned from everyone using the development code directly to now nobody using the development code for any real purpose. This has both been a great thing and a curse at the same time, as I have come to realize.
See the full mailing list post here.
I have made a post to the asterisk-dev mailing list describing a small project I am working on. I am making a way to create application timeouts, scheduled announcements, and periodic announcements that can be used with any Asterisk application. The results of the discussion will determine if this feature goes anywhere or hits the bit bucket.