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

[Dan Jenkins]

Yup, totally get your point as we've already discussed it on IRC... it just
feels like 4 years is an eternity. Most people don't move to a new version
of an LTS immediately and usually have a plan on how to upgrade - and its
not even like the LTS wouldnt include the module.... it just wouldnt be
enabled by default and ultimately thats what the changelog/upgrade.txt is
for isn't it?

4 years seems like a long time to get rid of something thats already been
decided isnt being looked after any more.

On Thu, Oct 1, 2020 at 5:27 PM Joshua C. Colp <jcolp at sangoma.com> 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/71016833/attachment.html>