Proposed Release Plan changes

Ludovic Hirlimann ludovic at
Thu Aug 9 05:18:51 UTC 2012

On 8/8/12 11:36 PM, Mark Banner wrote:
> Hi All,
> I just updated the Change of Release and Governance model 
> <> 
> wiki page with a revised section for Releases, this links straight to 
> a new etherpad containing the initial version of the proposed release 
> plan following the switch to the new model:
> Sorry for no pretty pictures, I'll put one together after we flesh it 
> out a bit more.

>   * All releases will be based on Gecko ESR releases
>   * To provide a more stable core for releases, so that we're not
>     affected so much by Gecko changes
>   * The ESR model will remain the same, separate from the mainstream
>     channel

Hum why that besides the channel change they'd be identical, I don't see 
the need to keep two channels with the same product. What's the point in 
keeping ESR and release based on the same ESR code ?

I don't see the point keeping Aurora and Beta. From the way it currently 
works we don't benefit much from having Aurora and Beta - most Major 
regression are found at release time not on Aurora nor beta and if they 
are they are found too close to the release dates to be actionable. 
Maintaining Aurora is too time consuming in terms of QA, release 
management and engineering for US to keep. I do see the l10 arguments 
but I think we can do it in another way (eg anyway most of the l10n 
strings from gecko we'll get for free from Ff).

I'de like us to consider the following :

  * We base release on ESR
  * When we have enough "new features"+bug fixes we cut a beta
  * Beta get's tested and released over a 3/4 week period
  * Next beta comes out a few months later which gives us time to chew
    on beta data (bugs, feedback etc ...)

What I'm proposing looks a lot like what happened for 3.0 or 3.1 eg 
reverting back to pre rapid release. I think this works better with how 
I see Thunderbird evolving and will give us more stable releases.


@lhirlimann on twitter

my photos

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
-------------- 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