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

Reply via email to