asterisk users - Jan 2006 - Asterisk Development and Release Cycle

Asterisk 1.2 was released over 1 year after Asterisk 1.0, which resulted
in many users trying to run the development version of Asterisk in a
production capacity so that they could take advantage of the new
features that had been added. This produced a flurry of extraneous bug
reports and caused extra work for the developers as they could not work
on changes that would actually cause disruption of the development tree.

In an effort to combat this problem, and to give the community a more
predictable release cycle, the process is being organized so that such a
long time between releases will never happen again.

Beginning in January of 2006, we will produce new major Asterisk
releases on a six month cycle.

The development cycle will be organized in this fashion:

MONTHS 1 - 3

The first three months of the development cycle are when the development
branch will be changed most drastically. The tree is open to large
architectural changes as well as new feature enhancements and bug fixes.

MONTHS 4 - 5

For the next two months, the development branch will no longer receive
architectural changes. New features that are ready to be merged will
still be accepted at this point.

MONTH 6

The last month is reserved for beta testing. No more features will be
accepted for the upcoming release. Beta releases will be made on a
weekly cycle, culminating in one (or two) release candidate releases
just before the final release.

Asterisk 1.4 is scheduled to be released in the beginning of July, 2006.
Once the release is made, a branch will be created. This branch will
then receive maintenance for bug fixes only. At that point, the
development cycle will start over to prepare for the next major release
of Asterisk, scheduled for January of 2007.

The Asterisk Development Team

This is great news.

Previously, stable was just considered a snapshot and if you ran stable and
encountered a bug, you had to switch to head to get the
fix.
This, of course, left you open to more possible bugs.

I think this change will make Asterisk more trustable for production use.

I understand that if you fall behind by not upgrading from one stable to the
next, you will lose that bug fix promise, but I was
never able to go to head in production because of too many unknowns.

I hope a fair number of sites will use head to find bugs and such, but for
asterisk to become even more of a force than it is now,
there has to be a maintained stable version.

Many thanks to the devs and other contributors for such a useful project.


-- 
-- 
Steven

May you have the peace and freedom that come from abandoning all hope of having
a better past.
---    -      ---  - - -       -    -     -   -   --  - - - --- - ------   - -
--- - - -- -  -    - --   -   -    -
"Asterisk Development Team" <asteriskteam@digium.com> wrote in
message news:43D174E4.7010408@digium.com...
> Asterisk 1.2 was released over 1 year after Asterisk 1.0, which resulted
> in many users trying to run the development version of Asterisk in a
> production capacity so that they could take advantage of the new
> features that had been added. This produced a flurry of extraneous bug
> reports and caused extra work for the developers as they could not work
> on changes that would actually cause disruption of the development tree.
>
> In an effort to combat this problem, and to give the community a more
> predictable release cycle, the process is being organized so that such a
> long time between releases will never happen again.
>
> Beginning in January of 2006, we will produce new major Asterisk
> releases on a six month cycle.
>
> The development cycle will be organized in this fashion:
>
> MONTHS 1 - 3
>
> The first three months of the development cycle are when the development
> branch will be changed most drastically. The tree is open to large
> architectural changes as well as new feature enhancements and bug fixes.
>
> MONTHS 4 - 5
>
> For the next two months, the development branch will no longer receive
> architectural changes. New features that are ready to be merged will
> still be accepted at this point.
>
> MONTH 6
>
> The last month is reserved for beta testing. No more features will be
> accepted for the upcoming release. Beta releases will be made on a
> weekly cycle, culminating in one (or two) release candidate releases
> just before the final release.
>
> Asterisk 1.4 is scheduled to be released in the beginning of July, 2006.
> Once the release is made, a branch will be created. This branch will
> then receive maintenance for bug fixes only. At that point, the
> development cycle will start over to prepare for the next major release
> of Asterisk, scheduled for January of 2007.
>
> The Asterisk Development Team
>
>
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> Asterisk-Users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>

Do Asterisk team care about this anymore?

Whole text can be found here:
http://www.asterisk.org/developers/releasecycle


--
Tomislav Par?ina
Lama Computers Split
Stinice 12, 21000 Split
Tel.: +385(21)495148
Mob.: +385(91)1212148
SIP: tomo@pbx.lama.hr
e-mail: tparcina#lama.hr
http://www.lama.hr

----- Tomislav Par?ina <tparcina@lama.hr> wrote:
> Do Asterisk team care about this anymore?
> 
> Whole text can be found here:
> http://www.asterisk.org/developers/releasecycle
Of course we care. Turns out that schedule was unrealistic, and when we start
the next cycle we will regroup and decide if we either stretch out the cycle or
reduce the amount of new functionality that gets added during the cycle.

-- 
Kevin P. Fleming
Senior Software Engineer
Digium, Inc.

In article <28047384.21361156888966912.JavaMail.root@jupiler.digium.com>,
kpfleming@digium.com says...
> Of course we care. Turns out that schedule was unrealistic, and when we
start the next cycle we will regroup and decide if we either stretch out the
cycle or reduce the amount of new functionality that gets added during the
cycle.
> 
OK, thank you for info.



--
Tomislav Par?ina
Lama Computers Split
Stinice 12, 21000 Split
Tel.: +385(21)495148
Mob.: +385(91)1212148
SIP: tomo@pbx.lama.hr
e-mail: tparcina#lama.hr
http://www.lama.hr

In article <44F4885E.5030205@sineapps.com>, matt.riddell@sineapps.com
says...
> I don't know.  Do you use Asterisk?  That makes you part of the team.
> 
> Have you tested the trunk version?  Provided assistance testing out
> patches waiting for completion?
> 
> Really, once all the new features have been completed, it will be released.
> 
> If you would prefer it to be released now (I.E. before everything has
> been tested and possibly fixed), just download SVN trunk.
Hi Matt,

Yes, I have downloaded SVN trunk. I'm using H264 codec from it.

There is one question I need to ask. How can I find out what are new options in
SVN trunk? Right now I know only for H264, where can I find the list of others?


--
Tomislav Par?ina
Lama Computers Split
Stinice 12, 21000 Split
Tel.: +385(21)495148
Mob.: +385(91)1212148
SIP: tomo@pbx.lama.hr
e-mail: tparcina#lama.hr
http://www.lama.hr

In article <44F56518.2060006@sanguinarius.co.uk>,
digium@sanguinarius.co.uk says...
> Err, wasn't the patch for H.264 just changing one digit for another?
Hi Thomas,

I don't know. I should check BUG page for that.


--
Tomislav Par?ina
Lama Computers Split
Stinice 12, 21000 Split
Tel.: +385(21)495148
Mob.: +385(91)1212148
SIP: tomo@pbx.lama.hr
e-mail: tparcina#lama.hr
http://www.lama.hr

In article <44F556BD.7040406@sineapps.com>, matt.riddell@sineapps.com
says...
> Other cool things:
> make menuconfig
> Jingle/jabber support
> IAX2 media transfers
> new sound files
> New answer machine detection (AMD)
> 
> and much much more!
Hi Matt, thank you for info!

Bye.

--
Tomislav Par?ina
Lama Computers Split
Stinice 12, 21000 Split
Tel.: +385(21)495148
Mob.: +385(91)1212148
SIP: tomo@pbx.lama.hr
e-mail: tparcina#lama.hr
http://www.lama.hr