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

[Dan Jenkins]

Fantastic idea Corey - that would get people knowing about things earlier
even if theyre not on a standard release.

On Thu, Oct 1, 2020 at 5:46 PM Corey Farrell <git at cfware.com> wrote:

> Any reason we can't "documentation deprecate" things in minor releases?
> No runtime warnings and keep building by default but if we deprecate a
> module in master right now it seems like the next minor release of all
> active branches should document the status of the module.  The fact that a
> module will still be supported on 16.14.0 doesn't stop us from telling
> users what will happen.
> On 10/1/20 12:25 PM, Joshua C. Colp wrote:
>
> On Thu, Oct 1, 2020 at 1:15 PM Dan Jenkins <dan at nimblea.pe> wrote:
>
>> Firstly, thank you Josh for trying to outline the process so that it's
>> something that can be followed and while I agree mostly with the steps...
>> the fact that its going to take 4 years for a module to be moved from
>> "deprecated" to being removed just feels too long but understandable if
>> we're talking about "this module has GONE from the source code"....
>>
>> I'm not really sure if my thought process here is tainted by the chan_sip
>> process that seems to have gone on for an eternity already.
>>
>> I personally don't see a problem with deprecating a module in non LTS and
>> removing it from being default enabled in the LTS - the code is still
>> there, and can still be enabled and packagers could still enable it. I
>> don't know what choices packagers make as to what gets built and what
>> doesn't as I don't use packages - each install f Asterisk has different
>> needs and so I always end up building from source. And then we could remove
>> it in the next standard release cutting the time by half.
>>
>> Would the above be ok if there was a "simple" way to say bring in
>> external modules at build time? IE movethe deprecated module to a separate
>> repo, and have the option to be able to bring it in dynamically during
>> build "at your own risk" - just like what happens with pjproject, codecs
>> etc....
>>
>> Or is that not really achieving the goal because there would still need
>> to be some sort of maintenance for these deprecated modules.....
>>
>
> That still incurs the maintenance burden in the first place. Even with an
> "at your own risk" perspective if you make it an easy ability to bring it
> in people will still have an expectation that it work, and when it doesn't
> then you need to deal with it in some way.
>
>
>>
>> I don't know... but essentially 4 years feels like forever and LTS and
>> Standard releases exist for a reason - I don't see why we need two LTS
>> releases before somethings removed.
>>
>
> The reason I opted for the way I did is that a portion of the user base
> don't run standard releases. They keep on LTS, so if you only do something
> in a standard release then they'll miss it. With my proposal standard
> release acts as an initial gauge of things before being released to the
> wider community. While I can understand the appeal of wanting to remove
> things as quickly as possible, it's not something I want to force as quick
> as possible upon the user base. It's a delicate balance to have so as to
> not drive people away, to give them time to transition and move, and to
> plan.
>
> --
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20201001/4eb058ee/attachment.html>