[asterisk-dev] Release Candidates and Nightly Builds
russell at digium.com
Fri Jan 18 19:30:37 CST 2008
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
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.
Senior Software Engineer
Open Source Team Lead
More information about the asterisk-dev