Fantastic idea Corey - that would get people knowing about things earlier even if theyre not on a standard release.
On Thu, Oct 1, 2020 at 5:46 PM Corey Farrell <g...@cfware.com> wrote: > Any reason we can't "documentation deprecate" things in minor releases? > No runtime warnings and keep building by default but if we deprecate a > module in master right now it seems like the next minor release of all > active branches should document the status of the module. The fact that a > module will still be supported on 16.14.0 doesn't stop us from telling > users what will happen. > On 10/1/20 12:25 PM, Joshua C. Colp 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