On Thu, 2020-10-01 at 20:14 +0100, Dan Jenkins wrote: > I'd argue two years isn't exactly quick... Especially with warnings > on previous minor releases after decisions have been made. 2 years > is fair - 4 is just too long. But if everyone else feels like 4 is > fine then I'll stop my protest ;)
I think it's a good starting point to go with 4... and then easier to perhaps quicken that to 2 in the future. =) -- Fred Posner f...@qxork.com https://qxork.com Direct/SMS: +1 (336) 439-3733 Need Fred? Call Fred. 336-HEY-FRED Matrix: @fred:matrix.lod.com > > On Thu, 1 Oct 2020, 20:09 Joshua C. Colp, <jc...@sangoma.com> wrote: > > On Thu, Oct 1, 2020 at 3:56 PM Dan Jenkins <d...@nimblea.pe> wrote: > > > 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. > > > > > > > Okay, so you'd like to see it be faster because in your opinion > > its better for the user base long term to force the transition > > quickly. > > > > I think I personally hesitate to be so aggressive because long ago > > the project was that way. We would push to remove things faster > > and such, and the result was upset people and complaints. Years > > later I still had people coming up to me at AstriCon talking about > > that stuff and how it screwed them over. > > > > -- > > 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
