[Asterisk-Dev] Asterisk release cycle.

[Jerris, Michael MI]

Eric Wieling wrote:
> Greg Boehnlein wrote:
> 
> > On Fri, 8 Apr 2005, Jerris, Michael MI wrote:
> > 
> > 
> >>Now this could be a worthwhile use for the patches stuff in the 
> >>makefile that mark had been playing with.  Then again, a 
> much better 
> >>way to do this would be to try to set a more frequent release 
> >>schedule, that would keep us from having features 
> unavailable to "stable" users for so long.
> >>Anyone for a 3 month cycle, head-->test-->release, shifting down 1 
> >>level every 3 months or so?  What do we need in place for "testing" 
> >>for this to be worthwhile?
> > 
> > 
> > If it were software for virtually anything else, I'd agree 
> with you, 
> > but quite frankly, PBX software should have pretty long 
> development, 
> > test and release cycles. People don't take to kindly to their phone 
> > calls just getting hung up on n such.. As many changes that 
> have gone 
> > into head, we should really let things flesh out for a while, keep 
> > adding fixes and at some point in the future announce a code freeze 
> > and just work on bug fixes before turning head into stable.
> 
> Asterisk does not have a long test cycle.  It has a long 
> development cycle where lots of new features are added, then 
> what always seems to me like a "let's just release the damn 
> thing and to hell with a long test cycle" policy.
> 
> Asterisk is both a young piece of software and a complex 
> piece of software.  You expect rapid development and many 
> changes as features are added and removed.
> 
> Here's an example.  You want to get extension routing 
> information from a remote place.  First there was the switch 
> => statement, then the 1.0.x database stuff, then SRV record 
> support, and then DUNDI, then the CVS-HEAD Realtime stuff.
> 
> All of these things let you get extensions out of 
> extensions.conf into something that works sort of like a 
> database.  Which one is best? 
> Hell if I know.  Each has it's advantages and disadvantages.  
> It seems to me that switch => and 1.0.x database stuff should 
> go away.  They were tried and eventually people realized that 
> there were better ways of doing things.  This is the way 
> young software works.

This is my point exactly.  A defined release cycle, either by time, or
some other milestone deemed appropriate, is necessary.  We should all be
pretty clear that a feature freze is not very practical with the speed
this project runs at.  A test branch would allow for appropriate testing
before anything is marked stable, or perhapse "release".  Along with
this, we need to start to build a suite of regression tests to verify
stability.  I am quite aware of the amount of work that would be
required to acomplish all this, and that Russel has a hard enough time
as it is getting any help with stable.  Please respond with other ideas.

Thanks
Mike