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