Strategy for handling the mozilla-2.0 branch
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.
There's two main stages to this plan, though the transition point is
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
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
o The version number would be 3.4a1pre (the lowest version bump
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.
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.
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...
More information about the tb-planning