Update 2014-02-11 The original plan for ESR was to do 3 extended support releases and then potentially EOL that branch and its associated resources. However as we've gotten more streamlined about supporting the ESR releases alongside mainline Firefox it's become fairly trivial to keep this branch running and with the mailing list becoming community-driven, even more so. As such there is no plan at this time to end ESR releases, the next ESR version will be 31 and each subsequent one will be 7 version numbers higher. At some point down the road we might need to reclaim the resources ESR uses, perhaps turn over the build generation to community, or other issues with backporting security fixes might become blockers that result in this branch being to rest.

For now, we'll continue the cadence and structure that has worked for the past 2+ years.

Note: This proposal has been accepted and implemented via bug 717106.

Introduction

The shift to a new release process has been difficult for organizations that deploy Firefox to their users in a managed environment. We've heard 2 primary concerns:

1. The release schedule doesn't allow sufficient time for the organizations and their vendors to certify new releases of the products
2. the associated end-of-life policy exposes them to considerable security risk if they remain on a non-current version past Firefox 3.6.

These groups — which include small & medium business, enterprise, academic, and government — want to continue to offer Mozilla products to their users, but they need a version of Firefox that gives them a longer support tail than what we currently offer.

This is a proposal for an Extended Support Release (ESR) for Firefox that will help meet those needs.

Notes:

• The proposal doesn't address organizations deploying Thunderbird. A Thunderbird-specific discussion is held on the Thunderbird Enterprise mailing list, and is documented here
• Product enhancements, such as Microsoft Scriptable Installer (MSI) and Group Policy Object (GPO) support are not part of this proposal.
• John O'Duinn has posted a proposal for maintaining the ESR from a Release Engineering point of view. This proposal addresses implementation and, if adopted, would affect organizations who deploy the ESR AND allow Firefox to update through its built-in updater. It does not affect the intent of the ESR proposal itself, but could limit the deployment time organizations that deploy the ESR and use Firefox's built-in updater to one release cycle (6 weeks). To our knowledge, most organizations that deploy the ESR would disable automatic updates, and this should not affect them.

Proposal

Mozilla will offer an Extended Support Release (ESR) based on an official release of Desktop Firefox. Releases will be initially maintained for nine release cycles (currently 54 weeks, which is close to the target of 52 weeks the proposal is attempting to hit), with point releases coinciding with regular Firefox releases.

To permit organizations sufficient time for testing and certification, the ESR will have a two cycle (12 week) overlap between the time of a new release and the end-of-life of the previous release. This will allow organizations who control updates (e.g. have disabled automated updates) to Firefox to qualify and test against Aurora and Beta builds for twelve weeks leading up to the ESR, and an additional 12 weeks to certify and transition to a new ESR. Organizations that rely on Firefox's built-in updater may be limited to a transition period of 6 weeks, dependant upon how the ESR releases are maintained.

The chart below outlines the process behind the creation and maintenance of the ESR, which will be based on release versions of Firefox Desktop.

This proposal (including dates and version numbers) has meanwhile been approved, announced and published.

Version Numbers

Update: Starting with Firefox ESR 24 the version numbering scheme has changed in order to make it more clear which ESR lines up with the rapid release versions and to make the chemspill versions more consistent. Going forward ESR versions will use the second digit in the version number to indicate which mainline version they match up to:

• 24.0esr => 24.0 mainline release
• 24.1esr => 25.0 mainline release security fixes
• 24.2esr -=> 26.0 mainline release security fixes
• and so on...

For chemspills this would mean:

• 24.1.1esr => 25.0.1 mainline release chemspill security fixes
• 24.2.1esr => 26.0.1 mainline release chemspill security fixes

The diagram below still accurately reflect how the ESR release matches to the release cycles of mainline Firefox, but the version numbers reflect the former scheme so please disregard those. Note: to update the diagram, see bug 1165777 for a .psd -- also need to update FAQ

Maintenance of each ESR, through point releases, would be limited to high-risk/impact security vulnerabilities and would also include chemspills (off-schedule releases that address live security vulnerabilities). Backports of any functional enhancements and/or stability fixes would not be in scope. At the end of the support tail the release will be end-of-lifed, no further updates will be offered for that version, and an update to the next version will be offered through the Application Update Service. Note: If a platform or locale is dropped in the next version, that platform or locale will be abandoned, and no update will be offered.

Mozilla will continue to collect additional information on deployment of Firefox in managed environments, and will work with community groups to facilitate adoption of the official releases of Firefox in those environments. Based on the data collected and adoption of the new release process over the course of maintaining the ESR, Mozilla would announce the continuation or impending end-of-life of the program. The initial proposal would be to support a minimum of two ESR releases.

Assumptions

• Firefox 10 will be the base version for the initial ESR and, assuming this is the case, Firefox 3.6 will be end-of-lifed on April 24th, 2012 (when Firefox 3.6 is end-of-lifed, an update to the current version of Desktop Firefox will be offered through the Application Update Service).
• The ESR release will use the same version number as the version of Firefox it is based upon (e.g. if the ESR is based off of Firefox 10, the ESR version will also be 10)
• The ESR point releases will follow Firefox conventions for point releases (e.g. 10.0.1, 10.0.2, etc.)
• The ESR release will use the same application GUID as Firefox
• Mozilla will backport security bugs qualified as "Critical" and "High" to the ESR where feasible (there may be cases where a backport cannot be applied with reasonable effort, and those cases are expected to be exceptional). Other security and stability backports to the ESR will be included at Mozilla's discretion.
• The ESR will be released day-and-date with the Firefox release it is based upon, to the best of Mozilla's ability to do so.
• Point releases to the ESR will run in parallel with the Firefox release schedule (e.g. point releases will be released every 6 weeks at the same time as a regular Firefox desktop release, chemspills when a Firefox chemspill is released)
• When an ESR reaches end-of-life, no further point releases or chemspill updates will be offered for that ESR, and an update to the latest supported version of the ESR (or Desktop Firefox, if the ESR for that platform is discontinued) will be offered to users of the end-of-lifed version
• The ESR will not be marketed through mozilla.com properties other than the Enterprise wiki page, staging servers, and/or blogs.

Caveats

• Firefox Mobile will not be maintained as an ESR
• Only those Operating Systems, or versions thereof, supported by the version of Firefox the ESR is based upon will be supported through the life of that release.
• Only those locales supported by the version of Firefox the ESR is based upon will be supported through the life of that release.
• Organizations that deploy the ESR would be strongly encouraged to participate in the Enterprise Working Group (EWG) to ensure they are kept abreast of developments, and can contribute feedback and assistance where needed.
• Organizations that deploy the ESR will be assuming a number of risks (see below), and must understand the implications of using the ESR versus the current release of Firefox.
• Mozilla will need to be crisp and clear in its messaging, to ensure that users of the ESR understand its limitations and risks, that they are accepting those limitations and risks, and to ensure expectations are set appropriately all around.

Benefits

• In keeping with the Mozilla Mission, the ESR will give deployment groups an alternative to IE for their users while maintaining/extending Firefox's footprint in a managed environment, which is in the tens of millions of users (or more!).
• The proposed ESR would provide those organizations with the time they need to maintain Firefox while pushing faster adoption of newer versions, provide a bridge to facilitate the adoption of Mozilla's new release cadence, or move back to IE or another product.
• Can be used as an opportunity to introduce product and process changes that facilitate certification and deployment, and will ideally move organizations to a point where faster release cycles become a non-issue in deploying Firefox.
• Helps Mozilla determine what is required to support a product for a period longer than our regular release cycle, and to build up additional expertise to be able to meet those needs without affecting critical path development.
• Gives Mozilla time to get a better read on the opportunities in a market space it is unfamiliar with.

Risks

• The ESR will not have the benefit of large scale testing by nightly and beta groups. As a result, the potential for the introduction of bugs which affect ESR users will be greater, and that risk needs to be understood and accepted by groups that deploy it. To help mitigate these risks, Mozilla will be asking organizations that deploy the ESR for assistance with testing alpha and/or beta builds of the ESR with their user base.
• Over time the ESR will be less secure than the regular release of Firefox, as new functionality will not be added at the same pace as Firefox, and only high-risk/impact security patches will be backported. It is important that organizations deploying this software understand and accept this.
• There is the potential for confusion among Firefox users between the regular release of Firefox and the ESR. To help lessen the potential of confusion between releases, the ESR will be an associative brand of Firefox (e.g. Mozilla Firefox ESR). Specific naming has not been finalized, but the intent is to be clear that the releases are based on a released version of Firefox.
• Maintaining the ESR will consume development resources that will impact the regular release of Mozilla products. Mozilla will need to build capability in back-porting, and will actively solicit the community for assistance in reducing the resource requirements of maintaining the ESR.
• The ESR is specifically targeted at groups looking to deploy it within a managed environment. It is not intended for use by individuals, nor as a method to mitigate compatibility issues with addons or other software. Mozilla will strongly discourage public (re)distribution of Mozilla-branded versions of the ESR.

Enterprise & Vendor Certification

One of the challenges of the ESR will be to shift testing and qualification methodologies used by deployment groups from reactive to proactive. Because the release schedule of the ESR will run in parallel with the Firefox release schedules, the release dates of the ESR and its point releases will be known well in advance.

The ESR will provide deployment groups and vendors with up to 12 weeks of testing and qualification, and an additional 12 week overlap between ESRs to certify and deploy the released version. The chart below outlines the Firefox ESR testing/qualification time-frames.

Additional Information (please review)

• Release Engineering's proposal for maintaining an ESR
• Meeting notes from the Enterprise Working Group call on Mozilla's Release Process