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
