<div dir="ltr">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.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 18, 2017 at 9:03 AM, Seán C. McCord <span dir="ltr"><<a href="mailto:ulexus@gmail.com" target="_blank">ulexus@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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><div><div class="h5"><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" target="_blank">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_6871152469459708878m_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/<wbr>wiki/display/AST/Asterisk+<wbr>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>
>> ______________________________<wbr>______________________________<wbr>_________<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/<wbr>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/<wbr>wiki/display/AST/Asterisk+<wbr>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><wbr>). 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_6871152469459708878m_7689776061312786327HOEnZb"><div class="m_6871152469459708878m_7689776061312786327h5"><br>
--<br>
Matthew Fredrickson<br>
Digium, Inc. | Engineering Manager<br>
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA<br>
<br>
--<br>
______________________________<wbr>______________________________<wbr>_________<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/<wbr>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>
______________________________<wbr>______________________________<wbr>_________<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/<wbr>mailman/listinfo/asterisk-dev</a></blockquote></div></div></div><div dir="ltr">-- <br></div><div class="HOEnZb"><div class="h5"><div class="m_6871152469459708878gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Seán C McCord<div>CyCore Systems, Inc</div><div><a href="tel:(888)%20240-0308" value="+18882400308" target="_blank">+1 888 240 0308</a></div><div>PGP/GPG: <a href="http://cycoresys.com/scm.asc" target="_blank">http://cycoresys.com/scm.asc</a></div></div></div>
</div></div><br>--<br>
______________________________<wbr>______________________________<wbr>_________<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/<wbr>mailman/listinfo/asterisk-dev</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Sidney H. VanNess, Ph.D.<div>President & CEO</div><div>On Call Central</div><div>p | 859-536-7137</div><div>e | <a href="mailto:sidney@oncallcentral.com" target="_blank">sidney@oncallcentral.com</a></div><div><br></div><div><b>NOTICE: Do not email support requests. Please direct all support requests to our ticket system located at: <a href="https://www.oncallcentral.com/support/" target="_blank">https://www.oncallcentral.com/support/</a></b></div></div></div></div></div></div></div>
</div>