Proposed changes to Asterisk release and support cycles

Home » Asterisk Users » Proposed changes to Asterisk release and support cycles
Asterisk Users 5 Comments

I’ve created a page on wiki.asterisk.org outlining some changes we’re proposing to make to the Asterisk release and support cycles. As always, before implementing any changes of this type, we’d like to collect some community feedback on the proposal.

The page is here:
https://wiki.asterisk.org/wiki/x/5ggiAQ

Feel free to comment here, or on the page itself if you find any errors or inconsistencies in the page’s content.

5 thoughts on - Proposed changes to Asterisk release and support cycles

  • Well said! This is also true of any type of long term supported release
    whether if it’s an operating system, application, etc. In the “LTS”
    name, it conjurs up thoughts of Ubuntu, but comparisons to RHEL/Fedora
    are far more appropriate I would think as Ubuntu focuses nearly
    exclusively on new point releases while backporting new features is what
    a company like Red Hat excels at and should be the prime example of how
    to run dual software channels (enterprise release in RHEL vs. hobby
    release in Fedora).

    Red Hat works so well for server systems because features are regularly
    backported with a *huge* emphasis on never breaking abi or build
    environments. So far there really hasn’t been a lot of noticeable
    features backported to 1.8.x that I’m aware of, but then again 10 is the
    first release after 1.8.

    Generally, if there isn’t a lot of support in maintaining a long term
    release, then it turns into merely a “old release that occasionally has
    quality security updates”. This is a perfectly valid approach too, but
    so far Digium’s use of “LTS” doesn’t really clarify clearly to me which
    type they are meaning to confer: 1) release that will stay static for
    its entire release sans security updates or 2) release that will stay
    compatible throughout the software’s life time while occasionally having
    features backported with development funded from paying clients with
    support contracts.

    It should also be said that the long term release really isn’t the
    appropriate place to debut new technology. If you absolutely require
    the newest stuff that Digium produces, regardless of their LTS paradigm,
    the LTS release probably isn’t meant for you. Using the RHEL/Fedora
    example of earlier, RHEL’s backports only come through around once a
    year during the point releases. Anything more would be chaotic and
    against the notions of a long term supported release. Fedora gets new
    stuff every 6 months, freshly baked with some stuff just not working all
    that well.

    I know distros and applications are two fundamentally different things,
    with entirely different goals and requirements, but I still think Red
    Hat provides the best example because 1) they have turned it into a
    science how smooth their development process goes in ratio to satisfied
    customers and 2) it’s the only other open source software project I can
    think of that can accurately compare. In a past meeting I had with
    Digium while working for another company, they too directly drew a
    correlation between the new LTS idea and ubuntu lts/non-lts and rhel/fedora.

    The conference app changes since 1.4 I haven’t been thrilled with, but
    in the whole time I’ve been supporting 1.8.x for my customers, I’ve come
    up with a very stable solution building on it and I haven’t had any
    surprises come my way.

    But think back before 1.8.x and Digium’s plan for LTS: We lived in a
    world where 1.4 bounced back and forth between “ultra-stable” and
    “whoops, dtmf is completely borked again” largely due to the fact that a
    complete rewrite of various parts of Asterisk would greatly undermine
    projects written specifically for that branch so small fixes netted
    breakage in other parts of the software. And we also had 1.6.x which
    for 95% of stuff was brilliant, but that other 5% was so crucial that it
    delayed adoption.

    Personally, I don’t think what Digium is doing is necessarily a perfect
    approach (hey, what is? we’re all human), but they’ve vastly improved
    the quality of Asterisk from a support perspective.

    *John Knight*
    Classic City Telco LLC
    *Email:* john@classiccitytelco.com *|* *Main:* (706) 995-0200
    *Direct:* (706) 995-0201 *|* *Mobile:* (706) 255-9203

  • Can you rephrase your question? This proposal does not change the
    planned lifetime of Asterisk 10 at all.

  • 1.8 and 11 forward all seem to have a timeline of around 5 years. 10 only
    runs for two. Since the code is available that isn’t a biggie to me, but
    the appearance of a “short life” could cause some customer discomfort.

  • 2012/1/31 John Knight

    I also agree that IMHO, Asterisk quality has vastly improved.
    Though nothing replace “field experience”, as a consequence, I feel much
    more confident when upgrading from one version to another.

    So if the previous plan which focuses development teams on fewer releases,
    still rules that would be OK for me as long as new Asterisk versions are
    carefully published (regression testing, …).

  • For the record: the next LTS (11) happens at a bad timing for Debian:
    the freeze is at about the same time of the planned Debian freeze. Which
    means that the release will just barely not make it, and we’re probably
    stuck with either 1.8 or 10 . Given that we’ll need to maintain it for
    ~4 years, 1.8 is preffered to 10.