[asterisk-dev] Module Deprecation, Default Not Building, and Removal

[Dan Jenkins]

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, <bweschke at 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 מערכות תקשורת <office at 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 <jcolp at sangoma.com> wrote:
>
>> On Thu, Oct 1, 2020 at 4:31 PM BJ Weschke <bweschke at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20201001/77ec7d97/attachment-0001.html>