[asterisk-dev] Release Candidates and Nightly Builds

[Russell Bryant]

Greetings,

I apologize for not being able to participate in the various discussions 
regarding release policies that have happened over the past week.  However, I 
would like to offer these thoughts in response to what has been talked about.

== Release Candidates

I hope that my plan for how to manage Asterisk 1.6 is satisfactory to everyone 
interested in helping to test releases.  I had already planned for a strong 
release candidate cycle.  Also, I plan to document the areas that received the 
most invasive changes in a release cycle to help focus testing efforts.

In regards to Asterisk 1.4, I feel that it is never too late to change policies 
if it makes sense to do so.  For 1.4, I would like to start creating release 
tags, and announcing them for testing.  Furthermore, I don't mind creating 
release candidate tarballs if it means that more people will participate in the 
testing.  I had already planned to create release tarballs for 1.6.

Furthermore, with Asterisk 1.4, previously we have immediately shipped out new 
releases for security fixes.  However, those releases also contained whatever 
other bug fixes we have made in the past few weeks.  I would like to change the 
policy such that we no longer do this.  When it comes time to fix a security 
issue, I would like to make an immediate release of the previous 1.4 release, 
with only the security fix applied.  With that in place, all regular 1.4.X 
releases can proceed with the quick release candidate and testing cycle.

== Nightly Builds

Note that as I am talking about nightly builds, I am talking about nightly 
tarballs, not binary releases.  However, I'm sure if someone else were 
interested in building specific nightly binary packages, I'm sure it could be 
automated against our nightly tarballs.

This issue has a lot more controversy than release candidates.  As a developer, 
I realize that technically, they provide no more access to the code than you 
already have with svn.  However, I am also willing to compromise and consider 
releasing code in other ways if it means that more people will actually use it. 
  It's probably a psychological thing, but it doesn't really matter.  If making 
nightly builds means more people will test the code, then I am all for it.

Before implementing this, though, I would like to gauge interest of this a bit 
more.  I will probably start another thread with a poll asking to see how many 
people would actually use nightly builds if they were available.  If the 
response is strong, then I can't see any reason for not doing it.

If we were to proceed with doing this, after discussing this with a few other 
developers, I think we can help keep track of nightly builds and bug fixes by 
using a naming convention that uses svn revision numbers.  For example:

asterisk-1.4-r99163.tar.gz  -- This would be a nightly tarball of Asterisk 1.4, 
from svn revision 99163.  That way, when bugs get reported to the bug tracker, 
we can easily see what fixes it does, or does not include.  Furthermore, when we 
fix a bug, and the automatic bug note indicates that it is fixed in revision X, 
then the user knows to get the nightly build that has a revision number greater 
than X.

The date of the nightly build would be available in the timestamp of the file on 
the downloads site.

======

As always, comments and suggestions are welcome.

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