[tor-dev] Syncing the Tor+TBB release schedules?

[Mike Perry]

On #tor-dev on IRC, I noticed Nick and Mark discussing trying to sync
the release schedules of Tor and TBB. I replied to Nick there with more
info, but it may be lost in scrollback. So I'm restarting the discussion
here. This email should give everyone on the tor-core side more info
than they ever wanted to know about the Tor Browser release schedule.


For Tor Browser, we are rather tightly bound to Mozilla's release
schedule on two timescales: a 6 week point release cycle, as well as a
42 week Extended Support Release cycle. You can see this release
schedule here:
https://wiki.mozilla.org/RapidRelease/Calendar#Future_branch_dates.

Note that schedule only lists the Rapid Releases, but there are Firefox
31-ESR point releases (with security fixes) on the same day as all Rapid
Releases. This is where our 6 week cycle comes from for Tor Browser, and
it is why we will always have a release on the same day as those Rapid
Release dates.

In terms of merge deadlines for our releases, Mozilla tags the all
releases one week prior to the actual release date. This means we
typically code freeze both TBB stable and alpha one week prior to
release, and begin building off of their new tags at that point. This
also means that the deadline for Tor Browser picking up a new Tor or PT
version is also roughly 1 week prior to those release dates.

The 42 week cycle comes from the Extended Support Release switch-over.
Every 7 Rapid Releases, Mozilla creates a new Extended Support Release
(ESR) series. We are currently on Firefox 31-ESR. The next ESR is
38-ESR. Note that the release calendar page lists Firefox 38 beta as due
on March 31st, and Firefox 38 as due on May 12th. We then have 2 more
rapid release cycles until Firefox 31-ESR is officially end of life.
This means we have until August 11th to rebase all of our patches, audit
and review Firefox 38, and write more patches for any issues we
discover.


So, how do these releases map to our upcoming TBB releases in terms of
our versioning and stabilization? Well, our plan for 4.5-alpha is to
freeze on March 26th, and then release TBB 4.5a5 on March 31st. We hope
to declare 4.5 stable soon after that (~2 weeks). It seems by
coincidence, Tor 0.2.6.x should be stable roughly around that time as
well. The reason why we are releasing 4.5-stable out-of-cycle is to
provide a 1 month grace period for people to still be able to run TBB
4.0 in case there are any catastrophes hiding in 4.5.

After that (in mid-April), we will branch a new alpha series
(5.0-alpha), which will target the next Firefox ESR release, based on
Firefox 38.

This means that from April until Aug 11th, the TBB team will be mostly
focused on the switch to FF38-ESR (reviewing changes, updating patches,
fixing tests, notifying Mozilla of patches they might like, etc).

On https://trac.torproject.org/projects/tor/wiki/org/roadmaps/CoreTor, I
notice that we currently have Tor 0.2.7 scheduled to be stable by
mid-Sept, which is slightly out of sync with a goal of shipping the
FF38ESR-based Tor browser and Tor 0.2.7.x-stable together on August
11th. 

This may place us in the weird position of shipping a TBB 5.0-alpha with
0.2.7 and FF38 for most of the FF38ESR stabilization period (April-Aug
11), and then having to decide if we want to just roll the dice on
0.2.7, or roll back to 0.2.6. Obviously both options will carry some
risk of instability.

As fair warning, I am very likely to decide that it will be better to
ship 0.2.7.x in TBB 5.0-stable on Aug 11th, as I suspect that the risk
from things like PT compatibility and control port compatibility issues
will actually make a rollback to 0.2.6 more risky on balance than
sticking with 0.2.7.x.



-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150312/8d21d9f3/attachment.sig>