If there was an additional message attached to minor releases, does that mean we can accelerate the steps?
On the question of why I'm opposed to 4 years? 4 years is an eternity to be in limbo - we've already seen this with chan_sip - even though its deprecated in 17, people still start using Asterisk today and use chan_sip because they don't know any better and a crap load of documentation out on the internet uses it. If the modules are deprecated, they're deprecated for a reason - kill them as quickly as reasonably possible and be done with it - it'll help everyone in the community long term. If someone disagrees with say getting rid of chan_sip then they can continue to run 17/18 or whatever - or they can take the contents of chan_sip, and apply them as a patch themselves. I'm picking on chan_sip here because its the current thing that caused these conversations in the first place. Dan On Thu, Oct 1, 2020 at 7:07 PM Joshua C. Colp <jc...@sangoma.com> wrote: > On Thu, Oct 1, 2020 at 2:28 PM Corey Farrell <g...@cfware.com> wrote: > >> Yes, or "core, deprecated in future versions" in the minors. I don't >> have strong feelings on the exact language just that we should indicate the >> long term future of a module has been decided. >> >> Also sorry I accidentally didn't send my last reply to the list. >> > > I think that's reasonable! > > -- > 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