[asterisk-dev] Asterisk 15 Beta Released

Wed Aug 23 08:48:10 CDT 2017

On Fri, Aug 18, 2017 at 8:14 AM, Sidney VanNess
<sidney at oncallcentral.com> wrote:
> Long time lurker and LTS user here. Resource constraints seem to be the
> underlying issue. Digium both has the right to focus on its bottom line, and
> change its policies when necessary. Seems as if the manner in which issues
> such as this typically get resolved in open source projects is to have those
> needs filled in by the community--nothing stops us from doing that. I agree
> that it would be good to know if this constitutes an official long term
> change in policy regarding LTS, however. Just my $0.02. Back to lurking.

Hey Sidney,

Thanks for responding and thanks for the understanding with regards to
balancing resource constrains.

With regards to the long term policy change, the intention is that 16
presumably will be the new LTS (instead of waiting for 17).

Hopefully that answers your question appropriately.

Matthew Fredrickson

>
> On Fri, Aug 18, 2017 at 9:03 AM, Seán C. McCord <ulexus at gmail.com> wrote:
>>
>> Matt,
>>
>>  would you care to expound on your reasons against 14.6 -> LTS?  I don't
>> have all the data, so I certainly don't discount the possibility that there
>> are compelling "reasons," but those that you gave, such as they are, are too
>> vague to form an argument against.
>>
>>
>> On Fri, Aug 18, 2017 at 5:07 AM Dan Jenkins <dan.jenkins88 at gmail.com>
>> wrote:
>>>
>>>
>>>
>>> On Thu, Aug 17, 2017 at 11:11 PM, Matt Fredrickson <creslin at digium.com>
>>> wrote:
>>>>
>>>> On Tue, Aug 15, 2017 at 1:15 PM, Dan Jenkins <dan.jenkins88 at gmail.com>
>>>> wrote:
>>>> >
>>>> >
>>>> > On Wed, Aug 2, 2017 at 10:57 PM, Matt Fredrickson <creslin at digium.com>
>>>> > wrote:
>>>> >>
>>>> >> It is with great pleasure I wish to inform you of the first beta
>>>> >> release of the new Asterisk 15 branch. It's a very exciting time to
>>>> >> be
>>>> >> a user of Asterisk! Asterisk 15 is arguably the biggest release of
>>>> >> Asterisk that has happened in the last 10 or so years. There has been
>>>> >> a lot of work done in the Asterisk core to better support newer
>>>> >> multi-stream video and WebRTC related technologies.  For those who
>>>> >> are
>>>> >> interested, much of this will be covered in blog posts at
>>>> >> http://blogs.asterisk.org/ over the next month or two.
>>>> >>
>>>> >> Typically, when a new major branch of Asterisk is created (13, 14,
>>>> >> 15...), there are a few months of testing on the new branch that
>>>> >> occurs prior to release in order to find regressions and other issues
>>>> >> that may cause a first official release from the branch to be dead on
>>>> >> arrival for a significant number of users. With today's release of
>>>> >> 15.0.0-beta1, this process has begun. Please feel free to start
>>>> >> testing this version of Asterisk in as many adverse environments as
>>>> >> possible. Any bugs should be reported on the Asterisk issue tracker
>>>> >> at
>>>> >> https://issues.asterisk.org/
>>>> >>
>>>> >> As a side note, due to many of the core changes in the 15 branch that
>>>> >> have been made since Asterisk 14 was released, it has been decided
>>>> >> that Asterisk 15 will not be an LTS release. For those of you who are
>>>> >> not familiar with the differences between LTS versus standard
>>>> >> releases, you can find more information here [1].
>>>> >>
>>>> >> Thanks to all the many Asterisk community members for providing so
>>>> >> much help and support to make Asterisk the great open source project
>>>> >> that it is.
>>>> >>
>>>> >> P.S. Binary codecs and other modules distributed by Digium are not
>>>> >> immediately available for 15.0.0-beta1, but should be shortly.
>>>> >>
>>>> >> Best wishes to all, and happy testing!
>>>> >>
>>>> >> [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions
>>>> >>
>>>> >> --
>>>> >> Matthew Fredrickson
>>>> >> Digium, Inc. | Engineering Manager
>>>> >> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
>>>> >>
>>>> >> --
>>>> >> _____________________________________________________________________
>>>> >> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>>> >>
>>>> >> asterisk-dev mailing list
>>>> >> To UNSUBSCRIBE or update options visit:
>>>> >>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>>>> >
>>>> >
>>>> > After talking to Sean McCord about this, I realised you didn't say
>>>> > anything
>>>> > about releasing a new LTS; which you don't _have_ to do but personally
>>>> > I
>>>> > have clients who are looking to use new features in 14 under an LTS
>>>> > and
>>>> > that's what we were expecting - I'm sure there are businesses out
>>>> > there that
>>>> > still want an LTS to move to.
>>>> >
>>>> > The reason we are all expecting an LTS is because of this line in the
>>>> > wiki
>>>> > on the page you linked to "New releases of Asterisk will be made
>>>> > roughly
>>>> > once a year, alternating between standard and LTS releases."
>>>> > (https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions)
>>>>
>>>> First off, thanks for expressing your sincere concerns with not making
>>>> 15 an LTS release :-)
>>>>
>>>> I know that this change will cause some difficulty for certain members
>>>> of the community, particularly with those that were expecting 14
>>>> related features to be in an LTS sometime soon.  This discussion is
>>>> something that has been on my mind for a while and the decision was
>>>> not made lightly.
>>>>
>>>> The major reason that it was decided to break convention and to not
>>>> make 15 an LTS is that there were some fairly considerable core
>>>> changes to Asterisk necessary to make the multi-stream work come
>>>> together to build an MVP video SFU out of Asterisk, which was our
>>>> goal.  Bearing that in mind, we did not feel comfortable building an
>>>> LTS release fresh off of those considerable core changes.
>>>>
>>>> We also anticipate a number of other considerable changes going into
>>>> the 15 branch as people start to play with the new SFU support.  Since
>>>> our proof of concept client is so bare bones (doesn't use Asterisk ARI
>>>> APIs yet) we expect there to be many of ARI API enrichments that are
>>>> likely to happen as people start to play with the new SFU support in
>>>> app_confbridge.  There are also potentially more fundamental changes
>>>> that could break clients if some of our initial behavioral assumptions
>>>> are incorrect, such as how app_confbridge reuses negotiated streams on
>>>> peerconnections or how new streams are negotiated and in what order.
>>>>
>>>> I know this places great difficulty on those who are using 14 features
>>>> counting on 15 being an LTS, but to be honest, I don't think that you
>>>> would want to use those features in a 15 LTS if you were concerned
>>>> about potential stability changes.  While we earnestly hope that 15
>>>> will continue 13 and 14's trend of being some of most solid stable
>>>> releases that have been cut, in an abundance of caution we decided to
>>>> break convention and make it non-LTS.
>>>>
>>>> > I'd like to propose that we make 14.6 (or later) the LTS in a similar
>>>> > fashion to how other communities are now promoting versions to LTS mid
>>>> > cycle
>>>> > (https://github.com/nodejs/LTS). That way you get to release all the
>>>> > exciting things that are in 15 but as a community we get LTS support
>>>> > on
>>>> > everything thats now in 14 - as we know, some businesses will not move
>>>> > to a
>>>> > non LTS and I think it would be a real shame to not get particular
>>>> > organisations moved over to using some of the great things that have
>>>> > been
>>>> > added in 14.
>>>> >
>>>> > What are everyone's thoughts?
>>>>
>>>> So from a project policy perspective, and due to the many other
>>>> burdens we have right now, I don't feel comfortable making this change
>>>> at this time.  I'm not saying it's never going to happen, just that I
>>>> can't imagine going forward with everything else going on right now.
>>>>
>>>> From a compromise position perspective, if your customers really would
>>>> like to get on an LTS with particular features that they're enjoying
>>>> in 14 (such as newer ARI changes, etc), there is a potential pathway
>>>> forward that might allow this sooner rather than later.  As long as
>>>> the changes they want are not of the nature to destabilize the
>>>> codebase (such as the DNS changes and a few others) or breaking API
>>>> changes, they can find a software developer to backport them into the
>>>> 13 branch.  Obviously, this requires submitting tests for features
>>>> that didn't have tests originally submitted.  But this would allow the
>>>> customer to have some of the new feature functionality of 14 in the 13
>>>> branch.
>>>>
>>>> I know that isn't exactly what you were asking, but perhaps it might
>>>> be another possibility for those who really want to remain on an LTS.
>>>>
>>>> Sorry to be the bearer of bad news on this :-(
>>>>
>>>> --
>>>> Matthew Fredrickson
>>>> Digium, Inc. | Engineering Manager
>>>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
>>>>
>>>> --
>>>> _____________________________________________________________________
>>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>>>
>>>> asterisk-dev mailing list
>>>> To UNSUBSCRIBE or update options visit:
>>>>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>>>
>>>
>>>
>>> So a compromise is having clients pay a developer to try and get those
>>> changes into 13? I don't really see that as a compromise personally. When
>>> those features were written, why weren't they written with tests and
>>> backported into 13? Because its more difficult and time consuming.
>>>
>>> Its all semantics at the end of the day - whether you release 14 as 15
>>> and then have 15 be a LTS and then release what is 15 beta to be 16 - its
>>> all just numbers. I don't want you to change your general policy on LTS
>>> version numbers specifically - I just want an LTS as described in the same
>>> wiki document you linked to - releasing 14.6 as an LTS is the way to do
>>> that.
>>>
>>> I don't really understand how as an open source project you can have a
>>> public policy and then change that policy _just_ when people are expecting
>>> that policy to come into force - if 6 months ago you had said "15 has a load
>>> of changes in it and we want to break our LTS policy" then I'm sure people
>>> would have thought and planned a bit more - but at this time we're just over
>>> a month until Astricon where typically, the new version of Asterisk is
>>> released, where we were expecting an LTS. This really leaves a bitter taste
>>> in the mouth.
>>> --
>>> _____________________________________________________________________
>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>>
>>> asterisk-dev mailing list
>>> To UNSUBSCRIBE or update options visit:
>>>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>>
>> --
>> Seán C McCord
>> CyCore Systems, Inc
>> +1 888 240 0308
>> PGP/GPG: http://cycoresys.com/scm.asc
>>
>> --
>> _____________________________________________________________________
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>
>
>
>
> --
> Sidney H. VanNess, Ph.D.
> President & CEO
> On Call Central
> p | 859-536-7137
> e | sidney at oncallcentral.com
>
> NOTICE: Do not email support requests. Please direct all support requests to
> our ticket system located at: https://www.oncallcentral.com/support/
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev

-- 
Matthew Fredrickson
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA