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

Mark Banner mbanner at
Thu Aug 15 20:26:27 UTC 2013

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.

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

More information about the tb-planning mailing list