[asterisk-dev] Asterisk 15 Beta Released

[Matt Fredrickson]

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