<div dir="ltr">Yup, totally get your point as we've already discussed it on IRC... it just feels like 4 years is an eternity. Most people don't move to a new version of an LTS immediately and usually have a plan on how to upgrade - and its not even like the LTS wouldnt include the module.... it just wouldnt be enabled by default and ultimately thats what the changelog/upgrade.txt is for isn't it?<div><br></div><div>4 years seems like a long time to get rid of something thats already been decided isnt being looked after any more.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 1, 2020 at 5:27 PM Joshua C. Colp <<a href="mailto:jcolp@sangoma.com">jcolp@sangoma.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Thu, Oct 1, 2020 at 1:15 PM Dan Jenkins <<a href="mailto:dan@nimblea.pe" target="_blank">dan@nimblea.pe</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Firstly, thank you Josh for trying to outline the process so that it's something that can be followed and while I agree mostly with the steps... the fact that its going to take 4 years for a module to be moved from "deprecated" to being removed just feels too long but understandable if we're talking about "this module has GONE from the source code".... <div><br></div><div>I'm not really sure if my thought process here is tainted by the chan_sip process that seems to have gone on for an eternity already. </div><div><br></div><div>I personally don't see a problem with deprecating a module in non LTS and removing it from being default enabled in the LTS - the code is still there, and can still be enabled and packagers could still enable it. I don't know what choices packagers make as to what gets built and what doesn't as I don't use packages - each install f Asterisk has different needs and so I always end up building from source. And then we could remove it in the next standard release cutting the time by half.</div><div><br></div><div>Would the above be ok if there was a "simple" way to say bring in external modules at build time? IE movethe deprecated module to a separate repo, and have the option to be able to bring it in dynamically during build "at your own risk" - just like what happens with pjproject, codecs etc....</div><div><br></div><div>Or is that not really achieving the goal because there would still need to be some sort of maintenance for these deprecated modules.....</div></div></blockquote><div><br></div><div>That still incurs the maintenance burden in the first place. Even with an "at your own risk" perspective if you make it an easy ability to bring it in people will still have an expectation that it work, and when it doesn't then you need to deal with it in some way.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>I don't know... but essentially 4 years feels like forever and LTS and Standard releases exist for a reason - I don't see why we need two LTS releases before somethings removed.</div></div></blockquote></div><div><br></div>The reason I opted for the way I did is that a portion of the user base don't run standard releases. They keep on LTS, so if you only do something in a standard release then they'll miss it. With my proposal standard release acts as an initial gauge of things before being released to the wider community. While I can understand the appeal of wanting to remove things as quickly as possible, it's not something I want to force as quick as possible upon the user base. It's a delicate balance to have so as to not drive people away, to give them time to transition and move, and to plan.<br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-family:tahoma,sans-serif"><font color="#073763">Joshua C. Colp</font></div><div style="font-family:tahoma,sans-serif"><font color="#073763">Asterisk Technical Lead</font></div><div style="font-family:tahoma,sans-serif"><font color="#073763">Sangoma Technologies</font></div><div style="font-family:tahoma,sans-serif"><font color="#073763">Check us out at <a href="http://www.sangoma.com" target="_blank">www.sangoma.com</a> and <a href="http://www.asterisk.org" target="_blank">www.asterisk.org</a></font><br></div></div></div></div></div></div></div></div></div></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>