[asterisk-dev] Asterisk 15 Beta Released

Dan Jenkins dan.jenkins88 at gmail.com
Fri Aug 18 04:06:57 CDT 2017


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20170818/bece99cb/attachment.html>


More information about the asterisk-dev mailing list