<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi All,<br>
    <br>
    A couple of months ago, it was proposed in the status meetings that
    we drop the optional intermediate release that was specified as an
    option in our <a
href="https://wiki.mozilla.org/Thunderbird/New_Release_and_Governance_Model">governance
      model</a> that we discussed last year.<br>
    <br>
    I'd like us to have a wider discussion on this, and so I have put
    together this proposal. We need to come to a resolution before the
    end of August, so that we have time to put anything necessary in
    place before we get to releasing TB 24.<br>
    <br>
    <b>What is being proposed?</b><br>
    <ul>
      <li>
        Drop the optional second release part way through the ESR cycle</li>
      <li>
        Merge both the mainstream ('release') and ESR update channels
        into the mainstream channel </li>
    </ul>
    <b>How would this affect development?</b><br>
    <ul>
      <li>
        The development cycles remain the same.</li>
      <li>
        The optional release was to enable significant new innovations
        to be released at shorter intervals. Obviously this would no
        longer be possible without re-separating the channels.</li>
    </ul>
    <p><b>How would this affect ESR?</b><br>
    </p>
    <p>I'm still examining the possibilities here, but my ideal would
      probably be to:<br>
    </p>
    <ul>
      <li>Release mainstream TB 24 off the ESR branch<br>
      </li>
      <li>When the next ESR is released, mainstream would be
        automatically updated to it</li>
      <ul>
        <li>However, we would do two more TB 24.0.x releases, that
          enterprises could pick up and deploy if they didn't want to
          upgrade to the next ESR straight away.<br>
        </li>
      </ul>
    </ul>
    <b>Why is this being proposed?</b><br>
    <br>
    This came out of a discussion at one of the status meetings. The two
    channels are effectively the same with the only difference in builds
    being the channel id, there's no significant point in unnecessarily
    confusing users.<br>
    <br>
    Whilst I've been keen to keep the possibility for the intermediate
    release open, the practicalities are that I don't see us needing to
    do an intermediate release, and like was commented at the original
    summit where we discussed the governance, doing an intermediate
    release in our current set-up may be complicated, especially for
    l10n and back-porting<br>
    <br>
    Additionally, having two separate channels that aren't varying means
    that we have to have duplicated builds. This means we have to go
    through the build and release process twice. Not having to do this
    would cut down the complications and also allow more time for other
    activities.<br>
    <br>
    <br>
    As I said above, feedback and comments are welcome - this is a
    proposal.<br>
    <br>
    Mark<br>
  </body>
</html>