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 <d...@nimblea.pe
<mailto:d...@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>
--
_____________________________________________________________________
-- 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
