Gecko versions for future Thunderbird releases

Kent James kent at caspia.com
Sat Jul 7 23:34:28 UTC 2012


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.

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.

comm-beta: stays on Gecko ESR. Patches are ported from comm-aurora to 
comm-beta to move them into TB-Main for more rapid introduction.

comm-release: the release channel for TB-Main.

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?

rkent



More information about the tb-planning mailing list