03-10-2011, 08:13 AM
Mozilla Firefox 4 Release Candidate
for Windows, Mac and Linux
Posted by Mozilla (http://blog.mozilla.com/blog/author/chrismozillacom/) March 9th, 2011
http://www.raidersmerciless.com/images/firefoxsm.pngMozilla Firefox 4 for Windows, Mac and Linux has exited the beta cycle and is now available as a release candidate (http://www.mozilla.com/firefox/RC) in more than 70 languages. The millions of users testing Firefox 4 will be automatically updated to this version and will join our Mozilla QA team in validating the new features, enhanced performance and stability and HTML5 capabilities in Firefox 4. Testers are encouraged to check out the Web O’ Wonder (http://demos.mozilla.org/) in order to see the future of the Web with cutting edge demos that showcase the incredible online experiences developers can now create. Developers can submit their own demos to the Mozilla Developer Network Demo Studio (https://developer.mozilla.org/en-US/demos/).
Thanks to our community of add-ons developers, more than 70 percent of Firefox Add-ons are now compatible with Firefox 4. If your favorite add-on isn’t marked as compatible, you can help test it using the Firefox Add-ons Compatibility Reporter. (https://addons.mozilla.org/firefox/addon/add-on-compatibility-reporter/?src=external-fxbetarelnote)
We build Firefox with help from our contributors and millions of beta testers. The team has fixed more than 8,000 bugs since the first beta release of Firefox 4. Please help test the release candidate and provide feedback (http://www.mozilla.com/firefox/RC/feedback/) to make sure Firefox 4 is the best it can be.
For more information:
Download Firefox 4 RC (http://www.mozilla.com/firefox/RC/)
Learn more about the features (http://www.mozilla.com/firefox/RC/features/)
Submit your feedback (http://www.mozilla.com/firefox/RC/feedback/)
Short, to the point FAQ (http://www.mozilla.com/firefox/RC/faq/)
Long, technical release notes (http://www.mozilla.com/firefox/4.0rc1/releasenotes/)
03-19-2011, 07:08 AM
Mozilla outlines 16-week Firefox development cycle
By Ryan Paul | Last updated about 22 hours ago
Although Mozilla is still readying Firefox 4 for its official release, the organization is already laying out its plans for subsequent versions of the open source Web browser. In a roadmap published earlier this year, Mozilla revealed plans to issue three more major releases during 2011--bringing the browser's version number up to seven.
As we discussed in our coverage (http://arstechnica.com/open-source/news/2011/02/is-mozillas-2011-roadmap-unrealistically-ambitious.ars) of the roadmap, Mozilla's plan is ambitious and will require a dramatic overhaul of the Firefox development process. Mozilla—which has historically had lengthy development cycles and protracted beta testing—will have to transition to a faster and less-conservative approach to release management. The organization has authored a document (http://people.mozilla.com/%7Esayrer/2011/temp/process.html) that describes how such a transition could potentially be achieved.
The document is still in an early draft stage and should be regarded as a proposal—not a finalized product plan, but indicative of the organization's thinking. Although it leaves some questions unanswered and there is still room for refinement, the strategy articulated by the document is compelling and illustrates the importance that Mozilla places on properly executing the procedural overhaul. Mozilla is clearly putting a lot of thought into this effort and is laboring to ensure that the transition will best serve Firefox's audience.
The document describes a 16-week development cycle in which software improvements will flow down through several tiers. The tiered model appears very similar to Chrome's channel system. New code will initially land in mozilla-central, the repository that hosts the tip of the code base. As new features solidify, they will roll through "experimental" and "beta" channels before arriving in a stable release.
Each of those tiers will be backed by its own code repository. Features will have to be implemented in a more compartmentalized fashion so that Mozilla can easily disable or withdraw functionality that is deemed unready for the final release. The proposal draft estimates that roughly 100,000 users would run nightly builds based on the code in mozilla-central. This group would likely consist of Firefox developers and contributors who are willing to tolerate some breakage and day-to-day changes to the user interface.
The experimental channel, which would have an estimated test base of roughly 1 million users, would be ideally-suited for Web developers who want to test the latest standards and Firefox add-on developers who want to experiment with new browser APIs. Beta releases, which will be suitable for widespread testing, are expected to attract a broader user base—as many as 10 million, according to the proposal.
It's worth noting that Mozilla already publishes nightly builds and beta releases. There isn't, however, anything that is quite analogous to the experimental channel in Mozilla's current pr-release lineup. Interestingly, the number of users actually running prerelease builds today is seemingly a great deal smaller than the estimates in the proposal.
The document describes a powers-of-ten pattern of audience growth between the nightly, experimental, and beta channels, but it's not really clear where that is coming from. To put it into perspective, it's worth comparing against a chart (http://www.mozilla.org/foundation/annualreport/2009/a-competitive-world.html) that Mozilla highlighted in November which cites 20,000 nightly build testers, 800,000 Firefox 4 beta testers and approximately 400 million users. Keep in mind, of course, that the proposal document is still a draft and there could be any number of possible explanations for the odd discrepancy.
One of the challenges posed by faster iteration is the intrusiveness of the update process. Frequent updates would be especially disruptive to users running the experimental and beta channels. The proposal document suggests silent background updates as a potential solution to the problem. It's worth noting that Mozilla is already transitioning to silent updates for minor fixes in Firefox 4. It will be possible for users to opt out if they prefer to manage updates themselves.
Arguably the biggest challenge for faster iteration is going to be the question of extension compatibility. The proposal document acknowledges that the problem exists but doesn't provide any suggested solutions. It's an area where Mozilla is going to have to do some serious problem-solving.
Firefox's robust add-on ecosystem is one of the browser's strongest differentiators, but keeping add-on developers aligned with the latest version of the browser is already a big challenge. Shortening the development cycle is going to exacerbate that issue profoundly. Users tend to not want to update until their favorite add-ons are compatible. Before moving forward with an incremental development strategy, Mozilla is definitely going to have to flesh out a plan for dealing with the extension issue.
Again, we want to emphasize that the proposal document is an early draft and there is still a lot of space for changes and improvements before Mozilla puts a plan into action. The real value of the document at this stage is that it shows how Mozilla is thinking about the transition. I still remain skeptical that Mozilla can deliver four major releases in one year, but the process proposal is a good first step that adds credibility to the existing roadmap.
Update: Mozilla's Mike Shaver has clarified the apparent discrepancy in the beta user estimates. He explained (http://arstechnica.com/open-source/news/2011/03/mozilla-outlines-16-week-firefox-development-cycle.ars?comments=1&start=40#comment-21448283) that the number of Firefox 4 beta testers has gradually increased to 2.5 million. When the new development process is instituted, Mozilla anticipates having a large consistent beta test group throughout the 16-week cycle rather than the current situation where the number of beta testers grows towards the end of a cycle and then drops off after a release as testers switch to the stable version.
vBulletin® v3.8.7, Copyright ©2000-2013, vBulletin Solutions, Inc.