Firefox developers have announced a reduction in the cycle of preparation of new versions of the browser within four weeks (the previous versions were prepared for 6-8 weeks). Firefox 70 will launch according to the above schedule on October 22then six weeks later On December 3, Firefox 71 version will be prepared, after which they will form subsequent releases every four weeks (January 7, February 11, March 10, etc.).
With which long-term version of support (ESR) will be released once a year as before and it will stay for another three months after the formation of the next version of ESR. Corrective updates for the ESR branch will be synced with the regular releases and will also be released every 4 weeks.
The next version of ESR will be Firefox 78, scheduled for June 2020. SpiderMonkey and Tor Browser will also be moving to a 4 week release build cycle.
The reason to shorten the development cycle it is the desire to bring new functions to users more quickly. More frequent releases are expected to increase the flexibility of product development planning and the implementation of priority changes that meet business and market requirements.
According to the developers, the four week development cycle allows for an optimal balance between the speed of delivering new web APIs and ensuring quality and stability.
Starting in the first quarter of 2020, we plan to ship a major version of Firefox every 4 weeks. The release cadence of Firefox ESR (Extended Enterprise Support Release) will remain the same.
In the years to come, we anticipate a major ESR release every 12 months with a 3-month support overlap between the new ESR and the end of the old ESR's useful life. The next two major releases of ESR will be ~ June 2020 and ~ June 2021.
Shorter release cycles provide greater flexibility to support product planning and priority changes due to business or market requirements.
With four-week cycles, we can be more agile and ship features faster, while applying the same rigor and due diligence required for a high-quality, stable release.
In addition, we put new features and implementation of new web APIs in the hands of developers more quickly. (This is what we've been doing recently with CSS spec implementations and updates, for example.)
Reduction of time needed to prepare for launch will lead to a reduction in testing time for beta releases, the nightly versions and the developer editions, which are planned to be compensated with more frequent updates for the trial versions.
Instead of preparing two new beta versions per week, it is planned to adapt the beta frequent release scheme for the beta branch, which was previously used for night versions.
To maintain quality and minimize risk in a shortened cycle, we must:
- Ensure that Firefox engineering productivity is not adversely affected.
- Accelerate the regression feedback loop from deployment to detection and resolution.
- Be able to control the deployment of functions based on the availability of the version.
- Ensure proper testing of larger features spanning multiple release cycles.
- Have clear and consistent mitigation and decision processes.
To reduce the risk of problems unforeseen by adding some significant innovations, the changes associated with its will be taken to version users not once, but gradually; Initially, the opportunity will be activated for a small percentage of users and then it will be fully covered or dynamically disconnected when defects are discovered.
In addition, to test the innovations and make decisions about their inclusion in the main team of the Test Pilot program, users will be invited to participate in experiments that are not linked to the launch preparation cycle.
Source: https://hacks.mozilla.org/
Mass alienation. We have become guinea pigs in all sectors of the industry.