<div dir="auto">Completely agree with Sean on the "what's going to be deprecated" question months before a cut. And I like the laid out plan that would be involved for 2 year process of deprecation,default enabled no and then remove.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 1 Oct 2020, 22:42 BJ Weschke, <<a href="mailto:bweschke@btwtech.com">bweschke@btwtech.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="auto">I don’t think anyone would have suggested beginning any process of removal of the chan_sip module when development of chan_pjsip first began. In fact, the discussion and decision of deprecation of chan_sip didn’t come about until AstriDevCon 2018 which occurred nearly 27 months after that July 2016 milestone. (<a href="https://www.asterisk.org/astridevcon-2018-a-recap/" target="_blank" rel="noreferrer">https://www.asterisk.org/astridevcon-2018-a-recap/</a>) <div><br></div><div><br><div dir="ltr">Sent from my iPhone</div><div dir="ltr"><br><blockquote type="cite">On Oct 1, 2020, at 5:03 PM, משרד GIS מערכות תקשורת <<a href="mailto:office@phonecall.co" target="_blank" rel="noreferrer">office@phonecall.co</a>> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr">as per my experience with systems built on top of asterisk not just vanilla asterisk it took like 4 full years from starting implantation for pjsip starting at 

<span style="color:rgb(0,0,0);font-family:monospace;font-size:13px">Mon, 04 Jul 2016 12: </span><div><span style="color:rgb(0,0,0);font-family:monospace;font-size:13px">>Added PJSIP tables and started integrating it<dd>First round of changes to introduce PJSIP... wow... it will be a huge blood bath, for start, you need asterisk 13.10 and chan_sip is not usable on 13.10. Stay tuned for next releases </dd></span> </div><div>till recently <span style="color:rgb(0,0,0);font-family:monospace;font-size:13px">on, </span></div><div><span style="color:rgb(0,0,0);font-family:monospace;font-size:13px">11 May 2020 00:55:54 +0200 </span><span style="color:rgb(0,0,0);font-family:monospace;font-size:13px">>Added a way to mass change the tech for extensions from chan_sip to PJSIP and back. It is available on Configuration/Extensions page </span></div><div><br></div><div>and still fixing bugs  94 fixis  in four years when doing major changes 4 years is needed minor stuff could go faster </div><div><br></div><div>think of all the guys who are running asterisk the last 5 years and need a complete change you need time plan sometimes the latest os when you have just another integration crm which for now can work only with   the older os etc </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 1, 2020 at 10:55 PM Joshua C. Colp <<a href="mailto:jcolp@sangoma.com" target="_blank" rel="noreferrer">jcolp@sangoma.com</a>> wrote:<br></div><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"><div dir="ltr">On Thu, Oct 1, 2020 at 4:31 PM BJ Weschke <<a href="mailto:bweschke@btwtech.com" target="_blank" rel="noreferrer">bweschke@btwtech.com</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><div style="font-family:Helvetica,Arial;font-size:13px">Four years, is indeed, really long. I do agree with this. As an example, I work with another project where the work involves some integrations with software that is in the head units of vehicles. Right now, they’re working to certify and lock down code and functionality for the 2023 vehicle model year which will hit dealer lots for the first time in just about two years from now. Once final certification occurs, in the vast majority of cases, nothing changes and the vehicles roll off the assembly line with the integration that was certified. If software that is involved in the manufacturing of vehicles can manage change risk within a two year window, it only seems reasonable that the Asterisk project should be able to do the same.</div></div></blockquote><div><br></div><div>From the development side we certainly can. The question is really - is it fair to the Asterisk user base, will they they accept it, will there be substantial backlash? The answer could be its fine. I don't really have a concrete answer though at this moment and likely wouldn't until put into action.</div><div><br></div><div>For a 2 year strategy I think it would go as such:</div><div><br></div><div>1. Minor releases receive change to indicate that module is to be deprecated in a future major release</div><div>2. Module is marked deprecated and defaultenabled no in standard release (19), which carries over to next LTS release (20)</div><div>3. Announcement and documentation for each includes notice of deprecated modules</div><div>4. Standard release after this it is removed (21), which carries over to next LTS release (22)</div><div>5. Announcement and documentation for each includes notice of removed modules</div><div><br></div><div>A wiki page would still be kept to keep track of modules in process of being removed.</div><div><br></div><div>Note that I'm just putting this out there so people see in comparison to the other one what the process would be like.</div></div><div><br></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>
<span>-- </span><br><span>_____________________________________________________________________</span><br><span>-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank" rel="noreferrer">http://www.api-digital.com</a> --</span><br><span></span><br><span>asterisk-dev mailing list</span><br><span>To UNSUBSCRIBE or update options visit:</span><br><span>   <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank" rel="noreferrer">http://lists.digium.com/mailman/listinfo/asterisk-dev</a></span></div></blockquote></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>