<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>With the current process new features can be added with tests can
      target 18 as soon as the branch is cut but would not go into
      18.0.  What would happen with new features in this scheme, would
      they just get held open in gerrit until 18.0 is branched or be
      accepted as normal since 18.0.0 release process is not yet
      started?  I agree a month is plenty of time for the release
      candidate cycle but think it would be good to decide how new
      features will be dealt with before 18 is branched.<br>
    </p>
    <div class="moz-cite-prefix">On 7/8/20 8:20 AM, Joshua C. Colp
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAM0A2Z0Rryvger4yYyTgY07otcxxJTfn1nCE0VR3G9z1yXX+Sg@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">Greetings all,
        <div><br>
        </div>
        <div>I've given this some thought in the past and thought with
          the impending branching of Asterisk 18 I'd get some input on a
          change to the process. The new major version process has
          evolved over time but hasn't really been changed lately. Let's
          look at what it is like in practice today:</div>
        <div><br>
        </div>
        <div>On July 15th under current process both the 18 branch and
          18.0 branches will be cut. The 18 branch will continue to
          receive all bug fixes, but the 18.0 branch will only receive
          changes as a result of issues found through testing 18.0 or
          through big fixes to new functionality in it. This means that
          when 18.0.0 is actually released it is generally a few months
          behind. In the past this was to give it time to stabilize as
          it were. This presents the following issues:</div>
        <div><br>
        </div>
        <div>1. It leaves a confusing area for developers where we have
          to ask "should this go into 18.0?"</div>
        <div>2. It confuses users because if they upgrade to 18.0.0 then
          it is likely the other current releases have bug fixes they
          don't have, which has caused issues for users in the past.</div>
        <div><br>
        </div>
        <div>I don't think this is the best situation for either.</div>
        <div><br>
        </div>
        <div>I'd like to propose that instead of cutting the 18.0 branch
          on July 15th we simply cut the 18 branch, and that it
          continues to receive all bug fixes. Approximately a month
          before a target release of 18.0.0 we create the first release
          candidate, 18.0.0-rc1. At this time we also create release
          candidates of the other branches. All release candidates will
          then be left available for a prolonged period of time to give
          people ample time to test. On the release date all will be
          released, ensuring that all branches including 18 have the
          same set of bug fixes as appropriate to their version.</div>
        <div><br>
        </div>
        <div>This removes the confusion for developers over whether to
          include a fix, since the 18.0 branch won't exist until rc1 at
          which point normal cherry pick rules apply. This also
          eliminates the confusion experienced by users since all
          releases will be on the same page at the same time at release.</div>
        <div><br>
        </div>
        <div>What do people think? Do we believe that a month out is
          ample enough? The 18 branch itself will exist, so that can be
          used for early testing (and likely will be). If a month isn't
          enough it could be moved out further. Really I think thanks to
          the testing that happens and the code review I don't think we
          need as long of a stabilization period as has been needed in
          the past, so this helps shrink it.</div>
        <div><br>
        </div>
        <div>Cheers,</div>
        <div>
          <div><br>
          </div>
          -- <br>
          <div dir="ltr" class="gmail_signature"
            data-smartmail="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>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
    </blockquote>
  </body>
</html>