[asterisk-dev] Asterisk 1.6 Release Management Proposal

[Russell Bryant]

Daniel Hazelbaker wrote:
> Since I already deleted that part of the thread and I am too lazy to  
> go dig it up...  From a "user" standpoint it doesn't sound like it  
> would be any different (or perhaps only slightly different) than  
> now.  At some point some "major" set of updates will be moved in  
> (remodeling the entire config file system, etc) that will bump  
> Asterisk up to 1.8, 2.0, whatever.  But for your average user when  
> 1.6.(X+1) comes out they will upgrade if either 1) it provides small  
> new features they have been waiting for; or 2) it fixes a bug they  
> are dealing with wether security or not just as they do now.
> 
> It seems like this change is more for developers than users (though  
> granted many users are developers in a project like this). To the  
> user the 1.6.x versions should simply be more stable than they have  
> been in the past.  To that end, it seems to me that as a matter of  
> normality security fixes should only need to be applied to the most  
> recent released 1.6.x version (which would become 1.6.x.y) and the  
> current development 1.6.x branch.  Obviously the development branch  
> so it makes it into the next version, but also a "quick fix" to the  
> released version so we don't have to wait for development to become  
> stable.

In short, these are the differences from the user perspective:

1) Asterisk 1.4.X releases did not different at all in terms of features.  The
changes are only bug fixes.  The 1.6.X release strategy is such that new
features will be added to every release.  So, the time that users have to wait
for features to make it into a supported release of Asterisk will drastically go
down.

2) Hopefully, the differences in the development will make Asterisk a more
stable platform.  It will drastically reduce the time between code getting
merged, and the time it gets tested and shipped in a release.  Also, we will be
dealing with smaller sets of new things at a time, making it easier to test and
debug regressions.

The issue when it comes to security is that people will have more of a reason to
stick to 1.6.0 versus upgrading to 1.6.1, because the changes will likely be
more significant than the things we do between 1.4.X releases.  So, because of
that, we should probably support multiple 1.6.X releases with security fixes.

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