<div dir="auto">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 ;) </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 1 Oct 2020, 20:09 Joshua C. Colp, <<a href="mailto:jcolp@sangoma.com">jcolp@sangoma.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr">On Thu, Oct 1, 2020 at 3:56 PM Dan Jenkins <<a href="mailto:dan@nimblea.pe" target="_blank" rel="noreferrer">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">If there was an additional message attached to minor releases, does that mean we can accelerate the steps?<div><br></div><div>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.</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div></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" rel="noreferrer">www.sangoma.com</a> and <a href="http://www.asterisk.org" target="_blank" rel="noreferrer">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 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 noreferrer" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a></blockquote></div>