Gecko versions for future Thunderbird releases

Kent James kent at caspia.com
Mon Jul 9 07:56:16 UTC 2012


On 7/9/2012 12:07 AM, Ludovic Hirlimann wrote:
> 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.

The problem with this is that once you base a release off of a non-ESR 
Gecko version, then you are pretty much forced to keep TB-main up to 
date with a changing Gecko so that you can provide security patches 
every six weeks. That is our current system. I thought that the whole 
intention of the proposal was to try to avoid the work of keeping up 
with Gecko changes every six weeks, and instead basing security updates 
(which still have to occur every 6 weeks) off of the slower changing 
Gecko ESR, which in theory should require very little work.

>> 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
In my interpretation of the basic slowdown proposal, comm-central is the 
main development repo, but all of the changes are only pushed to TB-main 
once a year. People who want a more up-to-date Thunderbird for testing 
purposes would use comm-aurora for that purpose.

As I said earlier, if as you propose TB-Main is based on 
mozilla-central, then you really have changed nothing, and aurora would 
need to continue to play whatever role it plays now.




More information about the tb-planning mailing list