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.
On Thu, 1 Oct 2020, 22:42 BJ Weschke, <bwesc...@btwtech.com> wrote: > 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. (https://www.asterisk.org/astridevcon-2018-a-recap/) > > > Sent from my iPhone > > On Oct 1, 2020, at 5:03 PM, משרד GIS מערכות תקשורת <off...@phonecall.co> > wrote: > > > 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 Mon, 04 Jul 2016 12: > >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> > till recently on, > 11 May 2020 00:55:54 +0200 >Added a way to mass change the tech for > extensions from chan_sip to PJSIP and back. It is available on > Configuration/Extensions page > > and still fixing bugs 94 fixis in four years when doing major changes 4 > years is needed minor stuff could go faster > > 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 > > On Thu, Oct 1, 2020 at 10:55 PM Joshua C. Colp <jc...@sangoma.com> wrote: > >> On Thu, Oct 1, 2020 at 4:31 PM BJ Weschke <bwesc...@btwtech.com> wrote: >> >>> 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. >>> >> >> 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. >> >> For a 2 year strategy I think it would go as such: >> >> 1. Minor releases receive change to indicate that module is to be >> deprecated in a future major release >> 2. Module is marked deprecated and defaultenabled no in standard release >> (19), which carries over to next LTS release (20) >> 3. Announcement and documentation for each includes notice of deprecated >> modules >> 4. Standard release after this it is removed (21), which carries over to >> next LTS release (22) >> 5. Announcement and documentation for each includes notice of removed >> modules >> >> A wiki page would still be kept to keep track of modules in process of >> being removed. >> >> Note that I'm just putting this out there so people see in comparison to >> the other one what the process would be like. >> >> -- >> 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 > > -- > _____________________________________________________________________ > -- 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