[asterisk-dev] Asterisk 15 Beta Released

Wed Aug 23 12:47:01 CDT 2017

I just wanted to know if it was an out-of-hand distaste or some more
fundamental complication.  Not enough timeshare is a perfectly acceptable
reason.  It's not like I have a whole bunch of free time to do release
engineering, after all, either!

Thanks

On Wed, Aug 23, 2017 at 9:59 AM Matt Fredrickson <creslin at digium.com> wrote:

> On Fri, Aug 18, 2017 at 8: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.
>
> Hey Sean,
>
> I think that Sidney hit the nail on the head.  Trying to go through
> that kind of change right now would be challenging, a lot of it due to
> preparations in getting 15 tested, released, and out there, Astricon
> preparations, and more importantly, AstriDevCon preparations and other
> things of that nature that are happening right now.  You'd never
> believe how much time it takes to make all of that come together
> (never mind all of the day to day demands).
>
> It's a non insignificant amount of work from just a project policy
> perspective to make a change like you and Dan are proposing.  I'm not
> completely opposed to the proposal, but my fallback preference is to
> just keep current policy and wait until 16 is released to cut a new
> LTS.  Or at the very least discuss this more after 15 is released.
>
> Matthew Fredrickson
>
> >
> >
> > 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 <(888)%20240-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
>
>
>
> --
> 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

-- 
Seán C McCord
CyCore Systems, Inc
+1 888 240 0308
PGP/GPG: http://cycoresys.com/scm.asc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20170823/255ddb6d/attachment-0001.html>