<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Whenever we approach an April release, we have to always be
      considering NGINX and the fact that around the same time we
      release a new stable version is cut from Mainline.</p>
    <p>What this means is, as NGINX decides to release a Stable version
      they use the NGINX Mainline branch to do more active feature
      development, feature implementations, etc. and then once it's cut
      'no longer support the older versions of NGINX' before it.</p>
    <p>Currently, we have been tracking NGINX 1.16.x which in April will
      become the "No Longer Supported" branch and at this point will be
      over a year old.  NGINX Mainline is currently at 1.17.5 and has
      bugfixes, feature changes/revisions/updates, etc. and will
      eventually become NGINX 1.18.x around when we release 20.04 LTS.</p>
    <p>In the past around the LTS releases we've switched from tracking
      NGINX Stable to NGINX Mainline in anticipation of a
      right-before-release or shortly-after-release upload to change the
      version string from 1.17.x to 1.18.0 to coincide with NGINX
      upstream releases.  I'm not fond of keeping 1.16.x in the repos
      for 20.04 LTS if I can avoid it, since it's technically no longer
      supported once NGINX releases upstream. around when we release
      20.04.<br>
    </p>
    <p>Do we want to pursue this approach of tracking Mainline again
      with the intention of FFes and MREs during the dev cycle up until
      the 1.18.x release after which we SRU that version string change
      that in?</p>
    <p>The other alternative is to keep 1.16.x in the repositories and
      then forcibly jump to 1.18.0 later but that's a more major version
      bump with a lot of feature changes.  (I'd like at least for 20.04
      to get on the latest NGINX Mainline branch with the intention of
      keeping it updated with FFes during dev and then a final version
      string change either just before or just after release to get us
      tracking 1.18.x as the version number.)</p>
    <p><br>
    </p>
    <p>I'd be happy to file any relevant requests to the Release Team
      ahead of time to get any of the devel cycle headaches handled.<br>
    </p>
    <p><br>
    </p>
    <p>Thomas<br>
    </p>
  </body>
</html>