Proposed Release Plan changes

Mark Banner mbanner at
Thu Aug 9 13:03:08 UTC 2012

On 09/08/2012 04:11, JoeS wrote:
> Well this has gotten me totally confused.
> from the original wiki post:
>   > There are currently two editions of Thunderbird: 'Thunderbird' and 
> 'Thunderbird ESR'.
>> Both will be maintained and based on the same Gecko engine release.
> Yet in the etherpad comments:
>>     Thunderbird Daily builds will be kept up to date and current 
>> nightly gecko
>>     Keeping these running gives us:
>>     continous integration with gecko updates avoiding a massive jump
>>     a safe place to land patches/improvements etc for the next major 
>> release
> If the first quote is correct, this means that the only way mainstream 
> users will see any community driven, or Gecko core improvements is 
> with a once a year release with the esr Gecko base.
Both quotes are correct. The plan is that the mainstream and ESR will be 
based on the same gecko release - but remember that's Gecko in the first 
statement, and we can take (via intermediate releases if there is deemed 
to be enough work to warrant them) Thunderbird specific changes later 
on. However, unlike previous methods of releasing, we still have a fixed 
date to say when a feature will be released.

Obviously, Gecko improvements would be restricted to once a year.

Keeping Daily builds running is just the obvious thing to do - that's 
where the next major release comes from, and by keeping them running it 
avoids a massive amount of work in uplifting between gecko versions. 
Typically, when Gecko breaks us currently (assuming it is something our 
builders/test boxes pick up), we get a fairly narrow regression range 
and that helps us pick up what changes we need really quickly. If we 
don't keep those running, it'd be a lot harder to find all the issues, 
especially because we'd likely have multiple failures.

> This separates the everyday user from the dev/testing community by a 
> full year. What use is community input via bugzilla.
Yes, this would increase that separation a bit. We had it before though, 
and I don't think it will cause us major pains. There may be some more 
duplicate reports, but it would also be good to consider what we can do 
to improve the handling of that gap. Maybe you could start a separate 
thread on that?


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

More information about the tb-planning mailing list