Proposal: Dropping the possibility for an intermediate release between ESR cycles

Ludovic Hirlimann ludovic at
Thu Aug 15 20:39:27 UTC 2013

On 15/08/13 22:26, Mark Banner wrote:
> Hi All,
> A couple of months ago, it was proposed in the status meetings that we
> drop the optional intermediate release that was specified as an option
> in our governance model
> <> that
> we discussed last year.
> I'd like us to have a wider discussion on this, and so I have put
> together this proposal. We need to come to a resolution before the end
> of August, so that we have time to put anything necessary in place
> before we get to releasing TB 24.
> *What is being proposed?*
>   * Drop the optional second release part way through the ESR cycle
>   * Merge both the mainstream ('release') and ESR update channels into
>     the mainstream channel
> *How would this affect development?*
>   * The development cycles remain the same.
>   * The optional release was to enable significant new innovations to
>     be released at shorter intervals. Obviously this would no longer
>     be possible without re-separating the channels.
> *How would this affect ESR?*
> I'm still examining the possibilities here, but my ideal would
> probably be to:
>   * Release mainstream TB 24 off the ESR branch
>   * When the next ESR is released, mainstream would be automatically
>     updated to it
>       o However, we would do two more TB 24.0.x releases, that
>         enterprises could pick up and deploy if they didn't want to
>         upgrade to the next ESR straight away.
> *Why is this being proposed?*
> This came out of a discussion at one of the status meetings. The two
> channels are effectively the same with the only difference in builds
> being the channel id, there's no significant point in unnecessarily
> confusing users.
> Whilst I've been keen to keep the possibility for the intermediate
> release open, the practicalities are that I don't see us needing to do
> an intermediate release, and like was commented at the original summit
> where we discussed the governance, doing an intermediate release in
> our current set-up may be complicated, especially for l10n and
> back-porting
> Additionally, having two separate channels that aren't varying means
> that we have to have duplicated builds. This means we have to go
> through the build and release process twice. Not having to do this
> would cut down the complications and also allow more time for other
> activities.
> As I said above, feedback and comments are welcome - this is a proposal.
I've always been in favor of this.

make testing easier (I don't need to test ESR so I can spend more time
on the release). It gives Enterprise user the stability they want - with
the caveats of major updates - but it makes it easier for them to use
the beta to test a few releases before. I don't see what we might miss
by dropping it - as anyway not so many people where aware of this.

I do believe that enterprise user should voice what they think about it
so adding them on cc here.


[:Usul] SRE Team at Mozilla
QA Lead fof Thunderbird

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

More information about the tb-planning mailing list