As some of you reading this may already know, there’s an proposal under discussion for how Mozilla could support releases for longer durations as requested by some enterprises.
I’d like to modify the latest Extended Support Release (ESR) proposal as follows:
1) Mozilla would not generate overlapping Extended Support Release (ESR) builds
2) Change the timing of when enterprises start to deploy new versions of Firefox.
The details of this are subtle, so please bear with me, while I try to explain with an brief example:
1) Mozilla anoints a specific Firefox release to be supported for a total of 42 weeks.
For the purposes of discussion, lets say this is Firefox 8.0. This means Firefox 8.0 users would be guaranteed to receive seven scheduled security-only dot-releases (plus, of course, any unplanned security chemspills that came up in that 42 weeks timeframe). Before the end of the 42 weeks, Mozilla would anoint another release to be supported for 42 weeks. To continue this example, after Firefox 8.0, the next release to be anointed would be Firefox 15.
Schedule-wise, this means:
** 8.0.1 would sim-ship with 9.0.
** 8.0.2 would sim-ship with 10.0.
…
** 8.0.7 would sim-ship with 15.0
** 15.0.1 would sim-ship with 16.0
…
2) Enterprises would start to verify/certify with the 8.0.0 release.
However, enterprises would *not* deploy 8.0.0. Specifically, enterprises would only start deployments of 8.0.1 at the time that 9.0 is released. (This is important for mechanical details about how updates are served – see more below.). (To be precise, enterprises deploy the latest 8.0.x available at the time 9.0 is released; if there are no chemspills, this would be 8.0.1, but if there are chemspills, it is always the latest latest 8.0.x available at the time of the 9.0 release).
3) When doing releases, RelEng makes a small change to how we publish updates between releases:
* 8.0.1 would sim-ship with 9.0.
** Mozilla would NOT enable updates from 8.0.0 -> 8.0.1
** Mozilla would enable updates from 8.0.0 -> 9.0.0
* 8.0.2 would sim-ship with 10.0.
** Mozilla would enable updates from 8.0.1 -> 8.0.2
** Mozilla would enable updates from 9.0.0 -> 10.0.0
…
* 8.0.7 would sim-ship with 15.0
** Mozilla would enable updates from 8.0.6 -> 8.0.7
** Mozilla would enable updates from 14.0.0 -> 15.0.0
* 15.0.1 would sim-ship with 16.0
** Mozilla would NOT enable updates from 15.0.0 -> 15.0.1
** Mozilla would enable updates from 8.0.7 -> 15.0.1
** Mozilla would enable updates from 15.0.0 -> 16.0.0
* 16.0.1 would sim-ship with 17.0
** Mozilla would enable updates from 15.0.1 -> 15.0.2
** Mozilla would enable updates from 16.0.0 -> 17.0.0
…
Thats it.
There are a few reasons why I recommend these modifications to the proposal:
1) Minimal changes to RelEng release automation or our update infrastructure. This means mechanically, we can put this new proposal into action more easily.
2) No need for any metrics infrastructure changes – all current infrastructure should just work as-is.
3) No need for Mozilla to generate overlapping concurrent ESR releases. This is significant because:
3a) the original proposal would have Mozilla sim-ship Firefox13.0, Firefox8.0.5esr and Firefox13.0esr at the same time as we also migrate aurora->beta and central->aurora. This is a significant increase in the mechanical work for RelEng in a *very* tight timeframe.
3b) this reduces the number of landings developers have to do for security fixes for 12-weeks-in-every-42 weeks. This also reduces the number of release builds to be generated if we have a chemspill in that 12-weeks-in-every-42-weeks window.
I believe these modifications still meet all the same objectives of the original proposal, yet are mechanically easier to implement. Therefore, I believe Mozilla could put this modified ESR proposal into action more easily then the existing ESR proposal.
Let me know if I missed anything, or if you have any concerns.
Thanks
John.
I think I understand your proposed scheme, and I can see your desire to have one enterprise update stream without generating overlapping ESR releases. But I’m not sure what you mean with the labeling in the diagram.
You have 12 weeks labelled as “certify/deploy” for 15.0.x, yet in your scheme, after 6 weeks 8.0.7 is going to be obsoleted by 15.0.1. I think that’s 6 not 12 weeks.
If you wanted to allow 12 weeks for certification (which IMHO is a good thing) and to have only one stream of ESR point releases (which is reasonable), then I think you’d need to branch the follow up to 8.0.x at 14.0 (the point at which you release 8.0.6) then, after 12 weeks certification time, release 14.0.1 concurrent with 16.0, and as an update to 8.0.7.
That might meet all your criteria. I recognise that the 14.0 -> 14.01 delta would be larger than normal to cover double the usual period of security fixes, so might take a little more developer effort, however the RelEng implications seem exactly the same as your proposal, and it does allow the 12 weeks certification time which is much desired.
BTW, I don’t understand the reasoning for your numbering scheme. If the ESR releases are called 8.0.x then what do you call an emergency security release of the mainline which occur between 8.0 and 9.0. I would imagine that what you’ve called ESR 8.0.1 should be called ESR 8.1 and an emergency release made just after 8.1 would be 8.1.1 (with 9.0.1 on mainline). Still that’s a minor point; release numbering discussions are boring…
[…] Based on the original ESR proposal, outlined by Mozilla vice-president of products Jay Sullivan here, it will be the non-profit that anoints the versions of Firefox that receives extended coverage. […]
[…] Back in October of last year, Mozilla began moving forward with plans for its Firefox Extended Support Release (ESR), designed to keep versions of Firefox maintained and patched with security fixes in order to cater to IT departments. This week, The Mozilla Blog announced that the ESR initiative is officially a plan of action. The move should go a long way toward helping the Firefox browser proliferate in business environments, where it has traditionally been viewed as untrusted. […]
[…] Based on the original ESR proposal, outlined by Mozilla vice-president of products Jay Sullivan here, it will be the non-profit that anoints the versions of Firefox that receives extended coverage. […]
[…] Based on the original ESR proposal, outlined by Mozilla vice-president of products Jay Sullivan here, it will be the non-profit that anoints the versions of Firefox that receives extended coverage. […]
I would like to know if I can install Firefox ESR on a 2008R2 server and push it thru GPO and would it run the latest updates?
I was wondering on the timetable for the next ESR of Mozilla Firefox. It appears Mozilla Firefox 17 will be coming out in November. Will Mozilla Firefox 17 ESR also be released in November?
https://www.mozilla.org/en-US/firefox/organizations/faq/
https://wiki.mozilla.org/Enterprise/Firefox/ExtendedSupport:Proposal
https://blogs.oracle.com/stevenChan/entry/firefox_extended_support_release_10#comments
Thank you because I am still a little bit puzzled with the timetable of the next ESR release of Mozilla Firefox.