Mark Banner's thoughts on Thunderbird, Mozilla, Bellringing and more.

Thunderbird 3.1a1pre – what’s that?

January 7th, 2009 Posted in Mozilla, Thunderbird

I’ve just checked in a change that will give Thunderbird builds a different version number depending on if they are build with mozilla-central (Gecko 1.9.2 builds) or releases/mozilla-1.9.1 (Gecko 1.9.1 builds). We’ve done this so we can start building and shipping updates for some new nightly builds. Here’s some Q and A that I hope will cover the various questions that folks will have:

Q. Is Thunderbird development branching?

A. Not until Thunderbird 3 beta 2 at the earliest. This diagram hopefully explains better how we’re going to be doing things:

Until we get to Thunderbird 3 beta 2, we will be keeping comm-central as one repository (Green line) but doing builds with mozilla-central (red line) and mozilla-1.9.1 (orange line). At some stage around or after beta 2, we will be branching comm-central, the branch will follow mozilla-1.9.1 and the trunk will follow mozilla-central.

Q. Is Thunderbird development being split?

A. No, until we release Thunderbird 3, that will be the main focus, even after we branch comm-central. The branch will, however, allow us to start work on trunk activities for the next version of Thunderbird as Thunderbird 3 development ramps down.

Q. What are the current versions of Thunderbird?

A. Thunderbird 3.0xx will form the next major release and will be released off of mozilla-1.9.1 (gecko 1.9.1).

Thunderbird 3.1xx builds will form the release after 3.0, currently based on mozilla-central which should form gecko 1.9.2.

Q. So the next release of Thunderbird will be 3.1?

A. Not necessarily. We may choose 3.1, 3.5, 4.0, 10.0 or anything else we want to think of. Seriously, no decision has been made about post Thunderbird 3 versioning or what will go into it. We’re using 3.1 because it is the next number in the range with the smallest increment. Once we have released Thunderbird 3, we’ll revisit this decision.

Q. Will nightly builds be available for the new trunk?

A. Yes, we should be getting these out in the next few days. We’d still like testers to focus mainly on the 3.0 builds, but these are available so we can check for regressions.

However, until we branch, we won’t be providing l10n builds until after we’ve branched – due to the required tools not being able to support the current build methods.

Q. Why are you doing comm-central with mozilla-central builds of Thunderbird?

A. Whilst we are in this not-fully split state, we would like to ensure that we don’t digress too far away from the changes going on in mozilla-central and therefore we want to provide some builds that can be used and tested. We’d still like the majority of testing to be done on the Thunderbird 3.0 builds.

The other advantage is that our trunk/branch build infrastructure will already be set up for when we branch comm-central.

Q. Where are the builds located?

The tinderbox builds are located on the “Thunderbird” (for 3.1 builds) and “Thunderbird3.0″ trees.

The 3.0 nightly builds will be available from or (this will be a symlink).

The 3.1 nightly builds will be available from . These haven’t been set up yet, so don’t expect them for a few days.

  1. 2 Responses to “Thunderbird 3.1a1pre – what’s that?”

  2. By Lillymon on Jan 7, 2009

    I really would’ve thought 3.1 would be the logical version number for the upcoming version of Thunderbird (since it’s based on Gecko 1.9.1), with 3.2 being the version after that. That way, Thunderbird would finally be back at version parity with Firefox, which is the way things should be.

    Of course, jumping from 2.0 to 3.1 would be rather odd, but so would having “Thunderbird 3.0″ being the email client paired to “Firefox 3.1″. At some point Thunderbird will have to make a version number jump if it’s ever going be at parity with Firefox, and I think the best time for that is now.

  3. By Standard8 on Jan 10, 2009

    @Lillymon: we’ve already advertised for ages that this will be 3.0, changing it now would just be wrong.

    Additionally I don’t think we need to be in sync with Firefox. We may decide to take different jumps at different times depending on how the two products evolve. Trying to take the same version numbers all the time just doesn’t make sense if there are different evolutions.

Sorry, comments for this entry are closed at this time.