Syncing the Tor+TBB release schedules?
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
On Thu, Mar 12, 2015 at 11:16 PM, Mike Perry <mikeperry@torproject.org> wrote:
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.
Hm. In that case, maybe we should consider aiming to have 0.2.7.x become stable around the end of July instead? That would require us to feature-freeze in mid-May, at the very latest. I'm not sure that gives us enough time to put out a solid release; we've never tried so tight a schedule before. This time around, our schedule looked like this: * Jun 18 -- Fork 0.2.5 as a place to put stuff that didn't fit in 0.2.4. * Sep 11 -- First rc for 0.2.5. * Oct 24 -- Stable release for 0.2.5 * Feb 2 -- Soft feature freeze for 0.2.6 * Feb 19 -- Hard feature freeze for 0.2.6 * Mar 9 -- First release candidate for 0.2.6 * Mar 20 (projected!) -- Stable release or second release candidate for 0.2.6 So if we aimed for a mid-May freeze, we would have to plan for a much smaller 0.2.7 than we had for future releases. (As it is, freezing 0.2.7 in August would still put it on a shorter timeline than we had for 0.2.6.) It's not out of the question, and we should make sure we talk about it when we're doing bug triage for 0.2.7 with Isabela next week. But another possiblility that maybe we should consider is to target 0.2.6 for your 5.0-x stable, and aim for 0.2.7 to go out in the next TB series? best wishes, -- Nick
This is a great discussion, thanks Mike for writing down TBB release process. I think is very important to start being more strategical on how we plan the different projects releases. Of course this doesn't mean we have to force a big change right away, that is why the discussion is important so we can figure out a good plan on how to do it. Let's see our options first: * match Core Tor release 0.2.7 with TB 5.0-x release o pros: PT and control port compatibilities o cons: probably will have to cut in half the number of features for 0.2.7 release (should analyze how that can affect sponsor deliverables we are committed to) * target 0.2.6 for TB 5.0-x stable, and aim for 0.2.7 to go out in the next TB series o pros? o cons? Did I missed anything? On 03/13/2015 07:00 AM, Nick Mathewson wrote:
On Thu, Mar 12, 2015 at 11:16 PM, Mike Perry <mikeperry@torproject.org> wrote:
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.
Hm. In that case, maybe we should consider aiming to have 0.2.7.x become stable around the end of July instead?
That would require us to feature-freeze in mid-May, at the very latest. I'm not sure that gives us enough time to put out a solid release; we've never tried so tight a schedule before.
This time around, our schedule looked like this:
* Jun 18 -- Fork 0.2.5 as a place to put stuff that didn't fit in 0.2.4. * Sep 11 -- First rc for 0.2.5. * Oct 24 -- Stable release for 0.2.5 * Feb 2 -- Soft feature freeze for 0.2.6 * Feb 19 -- Hard feature freeze for 0.2.6 * Mar 9 -- First release candidate for 0.2.6 * Mar 20 (projected!) -- Stable release or second release candidate for 0.2.6
So if we aimed for a mid-May freeze, we would have to plan for a much smaller 0.2.7 than we had for future releases. (As it is, freezing 0.2.7 in August would still put it on a shorter timeline than we had for 0.2.6.)
It's not out of the question, and we should make sure we talk about it when we're doing bug triage for 0.2.7 with Isabela next week. But another possiblility that maybe we should consider is to target 0.2.6 for your 5.0-x stable, and aim for 0.2.7 to go out in the next TB series?
best wishes,
On Fri, Mar 13, 2015 at 11:50 AM, Isabela <isabela@riseup.net> wrote:
This is a great discussion, thanks Mike for writing down TBB release process.
I think is very important to start being more strategical on how we plan the different projects releases. Of course this doesn't mean we have to force a big change right away, that is why the discussion is important so we can figure out a good plan on how to do it.
Let's see our options first:
[option 1]
match Core Tor release 0.2.7 with TB 5.0-x release
pros: PT and control port compatibilities
TB 5.0 gets _some_ new Tor features beyond whatever 0.2.6 provides.
cons: probably will have to cut in half the number of features for 0.2.7 release (should analyze how that can affect sponsor deliverables we are committed to)
Also, we might be tempted to avoid putting in larger features to 0.2.7 if we think that they might take more time. [option 2]
target 0.2.6 for TB 5.0-x stable, and aim for 0.2.7 to go out in the next TB series
pros?
TB has a stable Tor to include; Tor team can c
cons?
TB 5.0 doesn't get whatever improvements we do in 0.2.7.
Did I missed anything?
Option 3: Ship TB 5.0 with 0.2.7 in whatever state it happens to be when TB 5.0 is released. Pros: * As many new features as possible in TB 5.0 * Not much additional effort for the Tor team Cons: * Likely unstable Tor in 5.0; possibly buggy Tor in TB 5.0. Option 4: Ship TB 5.0 with a version of 0.2.6 including some items backported from 0.2.7 Pros: * TB has the features from Tor that the TB team thinks are most important. * TB ships with a pretty stable Tor. Cons: * Some stability risk, but less so than option 3. * Some high-complexity features may be too difficult to backport. -- Nick
Nick Mathewson:
On Fri, Mar 13, 2015 at 11:50 AM, Isabela <isabela@riseup.net> wrote:
This is a great discussion, thanks Mike for writing down TBB release process.
I think is very important to start being more strategical on how we plan the different projects releases. Of course this doesn't mean we have to force a big change right away, that is why the discussion is important so we can figure out a good plan on how to do it.
Let's see our options first:
[option 1]
match Core Tor release 0.2.7 with TB 5.0-x release
pros: PT and control port compatibilities
TB 5.0 gets _some_ new Tor features beyond whatever 0.2.6 provides.
cons: probably will have to cut in half the number of features for 0.2.7 release (should analyze how that can affect sponsor deliverables we are committed to)
Also, we might be tempted to avoid putting in larger features to 0.2.7 if we think that they might take more time.
[option 2]
target 0.2.6 for TB 5.0-x stable, and aim for 0.2.7 to go out in the next TB series
pros?
TB has a stable Tor to include; Tor team can c
cons?
TB 5.0 doesn't get whatever improvements we do in 0.2.7.
Did I missed anything?
Option 3: Ship TB 5.0 with 0.2.7 in whatever state it happens to be when TB 5.0 is released.
Pros: * As many new features as possible in TB 5.0 * Not much additional effort for the Tor team
Cons: * Likely unstable Tor in 5.0; possibly buggy Tor in TB 5.0.
Option 4: Ship TB 5.0 with a version of 0.2.6 including some items backported from 0.2.7
Pros: * TB has the features from Tor that the TB team thinks are most important. * TB ships with a pretty stable Tor.
Cons: * Some stability risk, but less so than option 3. * Some high-complexity features may be too difficult to backport.
Thanks for breaking out all the options, Isabela and Nick! After more consideration of all of them, given that these next few months will be spent mostly doing rebase work, I think either Option 2 or Option 4 above seem like the best plan. The only reason we should *need* new Tor features during the FF38 rebase effort is if the pluggable transports decide they need new Tor features in that timeframe. In fact, better PT support/fixes were the reason for most/all of our previous round of tor patch backports. Otherwise, we would just be including Tor 0.2.7 for more testing exposure. If the tor-core folks are fine waiting a bit longer before 0.2.7 sees a TBB release, I think it's fine for us to wait, too. -- Mike Perry
On Sun, Mar 15, 2015 at 4:30 PM, Mike Perry <mikeperry@torproject.org> wrote: [...]
Thanks for breaking out all the options, Isabela and Nick!
After more consideration of all of them, given that these next few months will be spent mostly doing rebase work, I think either Option 2 or Option 4 above seem like the best plan.
The only reason we should *need* new Tor features during the FF38 rebase effort is if the pluggable transports decide they need new Tor features in that timeframe. In fact, better PT support/fixes were the reason for most/all of our previous round of tor patch backports.
Otherwise, we would just be including Tor 0.2.7 for more testing exposure. If the tor-core folks are fine waiting a bit longer before 0.2.7 sees a TBB release, I think it's fine for us to wait, too.
Okay. Under this plan, when would we expect the first TBB alphas including 0.2.7 to come out? Some time in late august, or some time even later than that? -- Nick
Nick Mathewson:
On Sun, Mar 15, 2015 at 4:30 PM, Mike Perry <mikeperry@torproject.org> wrote: [...]
Thanks for breaking out all the options, Isabela and Nick!
After more consideration of all of them, given that these next few months will be spent mostly doing rebase work, I think either Option 2 or Option 4 above seem like the best plan.
The only reason we should *need* new Tor features during the FF38 rebase effort is if the pluggable transports decide they need new Tor features in that timeframe. In fact, better PT support/fixes were the reason for most/all of our previous round of tor patch backports.
Otherwise, we would just be including Tor 0.2.7 for more testing exposure. If the tor-core folks are fine waiting a bit longer before 0.2.7 sees a TBB release, I think it's fine for us to wait, too.
Okay. Under this plan, when would we expect the first TBB alphas including 0.2.7 to come out? Some time in late august, or some time even later than that?
It largely depends on how well the rebase goes. The safe estimate is mid to late August. If things go really well, we may be ready for an alpha sooner. Conceivably, we could even release a FF38-based TBB before the August 11th EOL, in which case we may be ready for an alpha series even earlier, but so far we've never moved that quickly. -- Mike Perry
Ok. let's triage 0.2.7 having this time frame in mind. Maybe it would be good to leave some 'capacity' for items that might be added along the way, so we can add feature requests or bugs if they come up. On 03/16/2015 10:45 AM, Mike Perry wrote:
Nick Mathewson:
On Sun, Mar 15, 2015 at 4:30 PM, Mike Perry <mikeperry@torproject.org> wrote: [...]
Thanks for breaking out all the options, Isabela and Nick!
After more consideration of all of them, given that these next few months will be spent mostly doing rebase work, I think either Option 2 or Option 4 above seem like the best plan.
The only reason we should *need* new Tor features during the FF38 rebase effort is if the pluggable transports decide they need new Tor features in that timeframe. In fact, better PT support/fixes were the reason for most/all of our previous round of tor patch backports.
Otherwise, we would just be including Tor 0.2.7 for more testing exposure. If the tor-core folks are fine waiting a bit longer before 0.2.7 sees a TBB release, I think it's fine for us to wait, too. Okay. Under this plan, when would we expect the first TBB alphas including 0.2.7 to come out? Some time in late august, or some time even later than that? It largely depends on how well the rebase goes. The safe estimate is mid to late August. If things go really well, we may be ready for an alpha sooner. Conceivably, we could even release a FF38-based TBB before the August 11th EOL, in which case we may be ready for an alpha series even earlier, but so far we've never moved that quickly.
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
participants (3)
-
Isabela -
Mike Perry -
Nick Mathewson