<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Along with the TB drivers, I've been thinking about a plan for
    handling the branching of mozilla-central (a mozilla-2.0 branch has
    now been set up).<br>
    <br>
    Comments and feedback on the plan are welcome.<br>
    <br>
    Mark.<br>
    <br>
    <br>
    There's two main stages to this plan, though the transition point is
    variable.<br>
    <br>
    <b>Stage 1</b><br>
    <br>
    This can go active when we've got the builders set up. This is based
    around sharing comm-central between mozilla-central and mozilla-2.0
    like we did when we initially started Thunderbird 3.1.<br>
    <ul>
      <li>Thunderbird 3.3 "branch"<br>
      </li>
      <ul>
        <li>These will build the comm-central repository with the
          mozilla-2.0 repository.</li>
        <li>Builders will report to a Thunderbird 3.3 tree.<br>
        </li>
        <li>We'd have some necessary build config for differentiating
          between branch and trunk versions.</li>
        <li>Developers would need to pull mozilla-2.0 separately (by
          specifying the repository argument to client.py).</li>
      </ul>
      <li>Trunk builders continue as they are</li>
      <ul>
        <li>These will continue building and running tests on
          comm-central plus mozilla-central</li>
        <li>The version number would be 3.4a1pre (the lowest version
          bump possible)</li>
        <li>We may not provide nightly builds initially - see discussion
          below.</li>
      </ul>
    </ul>
    At this stage, Thunderbird 3.3 will be considered the master tree -
    i.e. if there is burning on the trunk builders, but the 3.3 tree is
    green, you can still land patches into comm-central.<br>
    <br>
    <b>Stage 2</b><br>
    <br>
    We change to this stage when either a) the changes landing in
    mozilla-central are too great for us to cope with via ifdefs, or b)
    we are at the stage in the release cycle where we have completed the
    majority of the work for the release.<br>
    <br>
    This stage branches comm-central into comm-2.0 and we have two
    separate sets of repositories, just like comm-1.9.2/Thunderbird 3.1:<br>
    <ul>
      <li>Thunderbird 3.3 branch</li>
      <ul>
        <li>This would become a true branch, building comm-2.0 and
          mozilla-2.0</li>
      </ul>
      <li>Trunk builds</li>
      <ul>
        <li>These would continue as they are now, if nightly builds
          haven't been turned on by this stage, they would be at this
          time.</li>
        <li>comm-central would now revert to requiring trunk to be green
          before landing things.<br>
        </li>
      </ul>
    </ul>
    <br>
    <b>Nightly Builds</b><br>
    <br>
    I am proposing no nightly builds on the new trunk initially. I
    understand that some folks want to test on the latest cutting-edge
    code (including mozilla-central). However, my reasoning is that we
    currently have quite a small tester base, and we need to focus that
    tester base on what we are developing for - i.e. Thunderbird 3.3.
    We're not going to be landing new features in the "trunk" builds, so
    there's no significant need for a separate set of nightlies.<br>
    <br>
    Obviously, whilst we've got no nightlies on the "trunk" builds,
    we're at risk of regressions from mozilla-central that our unit
    tests don't pick up. We can handle finding regression points in
    multiple ways - analysing check in logs, generating builds via try
    server, using hg bisect etc.<br>
    <br>
    There may be a point before we switch between the branches that the
    drivers decide that we do need to start getting nightly coverage, if
    so, we'll turn nightly updates on and let everyone know.<br>
  </body>
</html>