Strategy for handling the mozilla-2.0 branch

Mark Banner mbanner at mozillamessaging.com
Mon Mar 14 15:41:45 UTC 2011


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).

Comments and feedback on the plan are welcome.

Mark.


There's two main stages to this plan, though the transition point is 
variable.

*Stage 1*

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.

  * Thunderbird 3.3 "branch"
      o These will build the comm-central repository with the
        mozilla-2.0 repository.
      o Builders will report to a Thunderbird 3.3 tree.
      o We'd have some necessary build config for differentiating
        between branch and trunk versions.
      o Developers would need to pull mozilla-2.0 separately (by
        specifying the repository argument to client.py).
  * Trunk builders continue as they are
      o These will continue building and running tests on comm-central
        plus mozilla-central
      o The version number would be 3.4a1pre (the lowest version bump
        possible)
      o We may not provide nightly builds initially - see discussion below.

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.

*Stage 2*

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.

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:

  * Thunderbird 3.3 branch
      o This would become a true branch, building comm-2.0 and mozilla-2.0
  * Trunk builds
      o These would continue as they are now, if nightly builds haven't
        been turned on by this stage, they would be at this time.
      o comm-central would now revert to requiring trunk to be green
        before landing things.


*Nightly Builds*

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.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20110314/80a268da/attachment.html>


More information about the tb-planning mailing list