Over time Mozilla has been trying to reduce the amount of time between developing a feature and getting it into a user’s hands. Some time ago we would do around one feature release of Firefox every year, more recently we’ve moved to doing one feature release every six weeks. But it still takes at least 12 weeks for a feature to get to users. In some cases we can speed that up by landing new things directly on the beta/aurora branches but the more we do this the harder it is for release managers to track the risk of shipping a given release.
The Go Faster project is investigating ways that we can speed up getting changes to users. System add-ons are one piece of this that will let us deliver updates to core Firefox features more often than the regular six week releases. Instead of being embedded in the rest of the code certain features will be developed as standalone system add-ons.
Building features as add-ons gives us more flexibility in how we deliver the features to users. System add-ons will ship in two different ways. First every Firefox release will include a default set of system add-ons. These are the latest versions of the features at the time the Firefox build was produced. Later during runtime Firefox will contact Mozilla’s update servers to ask for the current list of system add-ons. If there are new or updated versions listed Firefox will download and install them giving users access to the newest features without needing to update the entire application.
Building a feature as an add-on gives developers a lot of benefits too. Developers will be able to work on and test new features without doing custom Firefox builds. Users can even try out new features by just installing the add-ons. Once the feature is ready to ship it ships as an add-on with no code changes necessary for integration into Firefox. This is something we’ve attempted to do before with things like Test Pilot and pdf.js, but system add-ons make this process much smoother and reduces the differences between how the feature runs as an add-on and how it runs when shipped in the application.
The basic support for system add-ons is already included in current nightly builds and Firefox 44 should be the first release that we could use to deliver features like this if we choose. If you’re interested in the details you can read the client implementation plan or follow along the tracking bug for the client side of the feature.
8 thoughts on “Delivering Firefox features faster”
Is there any reason why Firefox is delivered as a whole package not just the changes. I mean why not have sometime like git diff.
I don’t know why there seems to be a difference between major releases and minor ones, but it seems like minor updates *do* get such a diff. If you’re on a prerelease (like nightly, dev or beta) the updates are small.
We do use diffs but generating those diffs involves completely building Firefox from scratch and the optimisation tools we use can do different things with every build meaning that even if you only changed a few frontend files the entire binary can be a bit different. This leads to needing to do more QA than would otherwise be necessary for the change.
so will this mean i can remove pocket, devtools and hello so if i get this rite then we can have a small firefox file to install which is verry bear bones and just install the plugins we need. This sounds cool there is to much cruft in ff rite now!
That’s not the intention of this no. The features we are talking about are what we consider to be core required features of Firefox. Firefox will still ship with them all and they shouldn’t be removed. It may make it easier for use to have a global option to say completely disable the Pocket functionality.
Part of the reason for the 6 week release cycles is to provide enough time both for new features to be tested by the Aurora/Beta audience, and for them to be localized. How will this be handled for system addons? Won’t this increase instability for users that are often struggling with update fatigue already?
It allows us to choose an appropriate release cycle depending on the feature rather than being locked into a six week cycle. In some cases they may stick with the regular six week cycle but just allow us to update faster in case of security or stability issues.
The update fatigue question is a real concern and we’re working with user research to help figure out how we can avoid making this worse.
But i dont want dev tools or any of the stuff i mentioned. Thay dont even work with a screen reader and i am not a webdev so y take up room on my computer. Stop tacking things on to Firefox just incase some one mite need them it is not a swis army knife. If you want to do that then just ship firefox with all the adons installed from the get go and we can have a nice 2-3 gig install package.
Comments are closed.