[asterisk-dev] Asterisk Release Schedule

[Olle E. Johansson]

7 okt 2009 kl. 21.52 skrev Russell Bryant:

> Greetings,
>
> This document discusses proposed changes to Asterisk release  
> policy.  I
> look forward to your feedback!
>
 From a quick reading, I can only say

FINALLY!!!!
Thanks for listening!!

>
>                    3. Release Numbering Scheme
>
> The Asterisk 1.6.X releases have played out differently than
> originally envisioned. The time between each 1.6.X release has
> been longer than expected, and the number of significant changes
> to the code has been quite high in each version. So, to better
> reflect the reality of what each new feature release contains,
> there will be no 1.6.3. Instead, the next feature release will be
> Asterisk 1.8.
>
> The numbering scheme can be interpreted as:
>
> <Concept>.<Feature>.<Minor>[.Patch]
>
>   * Concept - Something close to a complete rewrite would be
>     required to increase this number.
>
>   * Feature - An update to this number indicates an update to the
>     major feature set.
>
>   * Minor - This number reflects an update with bug fixes only.
>
>   * Patch - This number will be optionally used to reflect trivial
>     changes to a patch release. This is most often used for
>     security updates.
>
>
>                        4. Release Schedule
>
> The following table shows the release schedule for all existing
> Asterisk releases, as well as the schedule for the next planned
> release.
>
> +----------------------------------------------------------------+
> | Release | Release  | Release    | Security Fix    | EOL        |
> | Series  | Type     | Date       | Only            |            |
> |---------+----------+------------+-----------------+------------|
> | 1.2.X   |          | 2005-11-21 | 2007-08-07      | 2010-11-21 |
> |---------+----------+------------+-----------------+------------|
> | 1.4.X   | LTS      | 2006-12-23 | 2010-12-23      | 2011-12-23 |
> |---------+----------+------------+-----------------+------------|
> | 1.6.0.X | Standard | 2008-10-01 | 2010-04-01 ***  | 2010-10-01 |
> |         |          |            |                 | ***        |
> |---------+----------+------------+-----------------+------------|
> | 1.6.1.X | Standard | 2009-04-27 | 2010-04-27      | 2011-04-27 |
> |---------+----------+------------+-----------------+------------|
> | 1.6.2.X | Standard | TBD (Q4    | TBD + 1 year    | TBD + 2    |
> |         |          | 2009)      |                 | years      |
> |---------+----------+------------+-----------------+------------|
> | 1.8.X   | LTS      | TBD        | TBD + 4 years   | TBD + 5    |
> |         |          |            |                 | years      |
> +----------------------------------------------------------------+
>
> Table 1: Asterisk Release Schedule (*** Dates extended due to the
> timing of the new policy)
I suggest that we implement some extra testing for the LTS and maybe a  
status variable for it, like the good old "early", "stable" or  
something like that. Yes, it'll be hard to figure out. Number of bugs  
after a certain period after initial release, maybe is a judgement of  
the "stable" label.

I would also like a process for the developer group to decided whether  
a coming release will be a LTS or just a standard release.

I also abrubtly suggest that we terminate 1.6.0 to 1.6.1 releases  
early as it takes too much time for developers to maintain all these  
releases. Remove a year from them.

Again, thank you for listening. I've been waiting for a long time for  
this. Now we're back in serious business.

Before we make a final decision, I would like to see this short  
document merged into a final document, since it seems to build upon  
and change the current release schedule.

/O