Gecko versions for future Thunderbird releases

Ludovic Hirlimann ludovic at
Mon Jul 9 07:07:02 UTC 2012

On 7/8/12 1:34 AM, Kent James wrote:
> I've thought some about the proposal to have both an ESR and a regular
> version of Thunderbird, both based off of the slowly changing ESR
> Gecko. At first I liked the idea, but as I think about it some more I
> had some serious concerns. But I have some specific variations of that
> that I think might work.
> To even talk about it I have to call versions something, so let me
> define:
> TB-ESR: The existing and future ESR, with only stability and security
> changes incorporated.
> TB-Main: The regular Thunderbird releases, occurring more often than
> annually, and containing new features.
> TB-Next: Future TB to be based on the 2013 ESR Gecko release.
> The issue is, what happens with TB-Main. My understanding of the
> current proposal is that TB-Main be the main development branch, and
> be based on ESR Gecko. That is my concern. I fear an integration
> nightmare in 2013, coinciding with the hope to make that version the
> super-stable TB-ESR 2013. That is what I think will seriously fail.
Nah I think we should take TB-main based on mozilla-central.  I would
love TB-Next to be our beta ground. With a relaese every 6 weeks based
on gecko releases, we could effectively organize proper testing a few
times a year and thus deliver a top notch update for the next TB-ESR.
> As an alternative (or maybe this is the proposal and I don't
> understand it) what I would suggest is that TB-Main does not become
> the main development branch, instead we keep TB-next as the main
> development branch. But we would land specific patches from the main
> development branch into TB-main after they have baked on TB-Next to
> push certain bug fixes or new features earlier. TB-Main stays on ESR
> Gecko. (And while you are doing that, it would be great if there was
> also a mailnews interface freeze as well, so that anyone doing binary
> extensions would not have to recompile for each TB-Main release).
> If we keep the existing repositories, they would be defined as such:
> comm-central and comm-aurora: stay the same as they are now. Earlybird
> becomes the release of choice for early adopters. Perhaps Earlybird
> users stops updating nightly, and updates are pushed when a version is
> felt to be somewhat stable.
I don't see the point in keeping comm-aurora, from a release point of
view its scatters our users, and from a testing's perspective I don't
think it would bring much
> After the last TB-Main release for a given Gecko version, then aurora
> moves to beta, beta starts using the 6 week Gecko versions, until the
> coordinated TB-ESR/TB-Main release occur with a new Gecko version.
> I can imagine this working successfully. Is that roughly the plan?

@lhirlimann on twitter

my photos

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4435 bytes
Desc: S/MIME Cryptographic Signature
URL: <>

More information about the tb-planning mailing list