<div dir="ltr">Fantastic idea Corey - that would get people knowing about things earlier even if theyre not on a standard release.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 1, 2020 at 5:46 PM Corey Farrell <<a href="mailto:git@cfware.com">git@cfware.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>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.<br>
</p>
<div>On 10/1/20 12:25 PM, Joshua C. Colp
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">On Thu, Oct 1, 2020 at 1:15 PM Dan Jenkins <<a href="mailto:dan@nimblea.pe" target="_blank">dan@nimblea.pe</a>>
wrote:<br>
</div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">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"....
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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....</div>
<div><br>
</div>
<div>Or is that not really achieving the goal because
there would still need to be some sort of maintenance
for these deprecated modules.....</div>
</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div><br>
</div>
<div>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.</div>
</div>
</blockquote>
</div>
<div><br>
</div>
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.<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div style="font-family:tahoma,sans-serif"><font color="#073763">Joshua C. Colp</font></div>
<div style="font-family:tahoma,sans-serif"><font color="#073763">Asterisk Technical Lead</font></div>
<div style="font-family:tahoma,sans-serif"><font color="#073763">Sangoma Technologies</font></div>
<div style="font-family:tahoma,sans-serif"><font color="#073763">Check us out at <a href="http://www.sangoma.com" target="_blank">www.sangoma.com</a>
and <a href="http://www.asterisk.org" target="_blank">www.asterisk.org</a></font><br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
</blockquote>
</div>
-- <br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" rel="noreferrer" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a></blockquote></div>