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?
4 years seems like a long time to get rid of something thats already been decided isnt being looked after any more. On Thu, Oct 1, 2020 at 5:27 PM Joshua C. Colp <jc...@sangoma.com> wrote: > On Thu, Oct 1, 2020 at 1:15 PM Dan Jenkins <d...@nimblea.pe> wrote: > >> 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".... >> >> 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. >> >> 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. >> >> 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.... >> >> Or is that not really achieving the goal because there would still need >> to be some sort of maintenance for these deprecated modules..... >> > > 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. > > >> >> 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. >> > > 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. > > -- > Joshua C. Colp > Asterisk Technical Lead > Sangoma Technologies > Check us out at www.sangoma.com and www.asterisk.org > -- > _____________________________________________________________________ > -- 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
-- _____________________________________________________________________ -- 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