<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <div class="moz-cite-prefix">On 9/14/2012 9:30 PM,
      Unicorn.Consulting wrote:<br>
    </div>
    <blockquote cite="mid:50540461.5030406@gmail.com" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      <link href="chrome://translator/skin/floatingPanel.css"
        type="text/css" rel="stylesheet">
      <div class="moz-cite-prefix">On 15/09/2012 1:42 PM, Kent James
        wrote:<br>
      </div>
      <blockquote cite="mid:50540047.4040003@caspia.com" type="cite">I
        have an alternate proposal for the release planning. <br>
        <br>
        So my proposal is that we do "intermediate releases" to the main
        release channel starting at either TB 22 or TB 23. These would
        be releases from the main central/aurora/beta/release
        repositories so would not need additional repos with all of the
        complications of that. <br>
        <br>
      </blockquote>
      I think that an ESR release should not become an ESR release at
      the same time the general release occurs. ESR is really aimed at
      Business and they are in no hurry for new releases, so we do what
      business has been doing for almost as long as they have had
      computers, wait for the .1 release.  That is there will be a 17.1
      ESR and a 24.1 ESR or whatever no time frame as such, but released
      reasonably soon after the main release with fixes as required,
      including a roleup of the now almost mandatory 0.1 and 0.2.
      Releases.  The general user base can come along for the ride to
      point one, but point one is the ESR release.<br>
      <br>
      Matt<br>
    </blockquote>
    <br>
    OK I like that - and it could be done for the 17 series as well.<br>
    <br>
    So to interpret what I think you are saying in terms of repos and
    channels, we proceed with 17.0 as planned - but it is not the ESR
    release. We freeze mozilla-central in comm-aurora, release, and beta
    so that eventually release, beta, and aurora are all on gecko17. New
    work is landed in comm-central (with current gecko), and selected
    patches are landed in aurora (with a+) as needed in 17.1 (which will
    also be ESR). After 17.1 releases, we restart the
    central->aurora->beta migrations as now (but no new releases
    until 24.0 then 24.1 ESR)<br>
    <br>
    So we do the allowed 1 intermediate release, but we do it
    immediately so that hopefully central and aurora are close enough
    together that the backport is easy.<br>
    <br>
    If that is your proposal, I like it!<br>
    <br>
    :rkent<br>
  </body>
</html>