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

[Corey Farrell]

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 
> <mailto: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 <http://www.sangoma.com> and 
> www.asterisk.org <http://www.asterisk.org>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20201001/5768efe1/attachment-0001.html>