<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <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 class="moz-cite-prefix">On 10/1/20 12:25 PM, Joshua C. Colp
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAM0A2Z2FvAPUrM2sDXJiGUShNjWPAhXOKLpdvc4y5nspgHOLKw@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div dir="ltr">On Thu, Oct 1, 2020 at 1:15 PM Dan Jenkins <<a
            href="mailto:dan@nimblea.pe" moz-do-not-send="true">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" class="gmail_signature">
          <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" moz-do-not-send="true">www.sangoma.com</a>
                              and <a href="http://www.asterisk.org"
                                target="_blank" moz-do-not-send="true">www.asterisk.org</a></font><br>
                          </div>
                        </div>
                      </div>
                    </div>
                  </div>
                </div>
              </div>
            </div>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
    </blockquote>
  </body>
</html>