[asterisk-dev] Thoughts on Asterisk release management

[Matthew Fredrickson]

Russell Bryant wrote:
> Tzafrir Cohen wrote:
>> The point is: this tries to mimmic the success of the faster development
>> of Kernel 2.6. But with Kernel 2.6 there is a huge QA buffer between the
>> developers and the end users. s a result, servers have very diverse
>> kernel versions and upgrading to the latest to get a new feature is
>> sometimes not an option.
>>
>> I'm not saying that this is a bad idea. Just saying that when we get to
>> 1.9 , we'll still get bug reports from people running 1.5 . And asking
>> them to test with 1.9 wouldn't be a realistic option.
> 
> I would like to clarify that I do not want to replace our current model with
> this one.  I want to use it as a compliment to our current release model.  I
> would like to continue to maintain long release life cycles like we have for 1.0
> and 1.2.  However, in between these, I would like to have short development
> release cycles that mimic 2.6 kernel.

I have had similar thoughts about this as well.  The 2.6 kernel has been 
a good example of how to bridge the ~1.5 year gap that typically occurs 
during the development cycle, so that when there are problems it doesn't 
take a year and a half to even know about them.

 From the Zaptel perspective, we are already moving to a 2.6 style 
development pattern, at least for non major changes to the architecture, 
since it more closely follows what our needs are.

So, is your proposal basically to move Asterisk as well to a linux 
kernel 2.6 style kernel release cycle?

-- 
Matthew Fredrickson
Software/Firmware Engineer
Digium, Inc.