[asterisk-dev] Asterisk Project Software Configuration Management Policies

Olle E. Johansson oej at edvina.net
Tue Nov 13 03:47:35 CST 2012


13 nov 2012 kl. 07:47 skrev Tzafrir Cohen <tzafrir.cohen at xorcom.com>:

> Thanks for the summary,
> 
> On Mon, Nov 12, 2012 at 11:44:18AM -0600, Matthew Jordan wrote:
>> Hey all -
>> 
>> Continuing down the list of 'things we discussed at AstriDevCon and
>> decided we really should write down', the following wiki page describes
>> various things that loosely fall into the category of "Software
>> Configuration Management":
>> 
>> https://wiki.asterisk.org/wiki/display/AST/Software+Configuration+Management+Policies
> 
> I'm trying to understand the role of the Standard versions. They don't
> intend to provide a stable API. So they are some sort of playground
> versions, right?

I would label them "development releases".

My question here is the LTS brand. A new release is far away from something we
can use in production at larger sites. For 1.4, it took almost two years until it was
production ready. 1.8 is close to getting there, but still require some more work.

Labeling a brand new release LTS is a way to encourage testing, but I would prefer
it being "LTS candidate" for at least a year. 

I have no experience of a process to evaluate for LTS - but it should at least be
able to pass most users dialplan tests without core dumps. Maybe an evaluation
of the bug tracker input could be used.

I do hope that if this policy is adopted, that we get rid of the "certified" releases.

I also lack a process to handle new code that is defered to the next standard release
after the LTS is released. Code in svn branches and the bug tracker seems to be forgotten.

/O


More information about the asterisk-dev mailing list