Firefox moving to 4 week releases

Getting features out to people faster means shorter feedback cycles.

Regarding versioning, most applications don't use semantic versioning; that's mainly for libraries. Not sure what "backwards incompatible" would mean for a browser, anyway.

Then feedback, if you rollout release too frequently you also can be several releases in and get feedback of some bug in a release prior to current release, albeit only a week or so. So by having organised releases, allows better management and a better experience overall. It's a fine balance, but for those who needs it, there will always be nightly builds of most things they want with last second updates, also self-builds for those inclined.

But I get the whole artificial timeframe does seem somewhat odd, but the further you look at the overall usage, management and support factors et all, you start to appreciate such regular timeframes.

On the other extreme, I've worked in an environment in which a whole suit had to be retested and go thru all the hopes as a full stop was missed of a comment and that change caused the whole testing, management/release cycle to go thru the motions again. That you would like, ignore and package up with other small things into a full release - which is what many do these days in most environments. After all - would you want to go thru a rollout of a new release that may contain a fix you want, or equally may just be adding a full stop to a comment in the code and yielding no binary level changes, albeit that it went thru the whole hoops and hurdles as a full release and that is what you got.

So from my experience, a 4 week release cycle is good, fixed, something that you can plan around. Also kudos for not just picking a day a month and doing monthly updates like most, that tends to seem more arbitrary unlike 4 weeks, which has an air of less arbitrary and feels like it was thought out more. Though an element of personal experience does come into play.

Exactly my thought - why 4 weeks? Why not just put everyone on Nightly and be done with it? Then everyone will enjoy the firehose of agility and features that is Mozilla! You're always shipping working code, right? If it passes the harness, it's good, isn't it?

At some point you need to say this is what we want to ship, and branch, and make sure that not only all tests pass, but that the installers work, run the benchmark suite that might not be run on every PR, make sure the updates work on all systems, appstores, etc. Accept new patches to fix bugs, etc.

I suppose they might have a release team that does nothing but releases, and if creating a full release takes a week (no idea how long it takes honestly), then maybe they could release each week.

But I don't think they can release a new version every day, because probably running their whole CI takes longer.

E.g. before shipping a version of Rust, the RC is used to build and run tests of all packages in the Rust package repository. This takes 4 full days. One could probably throw money at the problem and speed it up, but at least right now, releases just cannot technically happen faster, unless you are willing to compromise on quality.

Not part of the talk: if you have more than 3 people involved you probably need a release schedule in terms of either scope or time. I'd personally advise you to have one even if you only have 1 person, just for a mental target if nothing else.

The talk goes into studies of projects which did scope based releases and got horrible results in practice. All the ones in the talk switched to time based releases and were much happier. Also, in a software project, you can only fix either scope or time, but not both. Also, if you want to ship in a timely manner, you probably want to fix one of them, not let both float.

Edit: it looks like this is his paper on the topic: http://www.cyrius.com/publications/michlmayr_fitzgerald-time...

I feel like it might help with motivation. It's easy to push things "to tomorrow" if you don't have a hard cap on how many tomorrows are available before the feature is supposed to go out.

> If people demand a certain new feature ("[this will] bring you new features more quickly"), it can just be brought out as it's ready, instead of having to wait an average of 3 (now 2) weeks before it can be released?

It's kind of like forming a habit. Having a set schedule could in theory delay quick features, but it will also keep the motivation going for time-consuming features.

> And why does this have to increment the major version, since when is every single update backwards incompatible?

I actually really like this personally. Encoding compatibility in a version number is, IMO, useless— it's sometimes just hard to know if your changes will break something or not, so there's a wealth of minor versions out there that break things anyway.

Just using a single number just makes everything simpler. Detecting breaking changes should be done with systems (tests, static analysis, etc) and not by trusting a number some developer came up with.

When the cost of the release goes above a certain amount, due the sheer number of features or the thoroughness of the release process, it starts to make sense to mutualize release tasks between a bunch of features.

Bundling those features on a time basis is quite often a local optimum between an acceptable delay for the product team and an acceptable cost for ops/release/qa/...

For server-side software, it's easy enough to do multiple releases per day, because you have full control over the environment, and all the work is internal. But for desktop/mobile software like this, having multiple releases per day won't be efficient in terms of bandwidth, load, or user experience.

And each browser version has other external costs, like documentation and support. Right now it can be hard to solve a problem like, "How do I do X with Firefox" because the answer varies by version. The more versions you have, the harder that is.

Or can you imagine trying to triage and verify bug reports if there are, say, 3 new Firefox releases per day, and people could be on any one of dozens of versions because they don't quit and restart the browser very often? We can imagine solutions to these problems, of course. But I think getting a release cadence below weekly for desktop apps will be a very long road.

https://herbsutter.com/2019/07/13/draft-faq-why-does-the-c-s...

My 2 cents, speaking from some experience working on long time cycle projects and shorter cycle projects.

Use ESR, or only read release notes every 6 months.

Short release cycles also mean much shorter release notes. The average FF changelog has a dozen minor items or so, it takes 5mn to go through it.

IME frequent updates terrify non-technical users, any given update might change the UI, remove a feature the use or add some other complication (like simply not working) at an inopportune moment. Big fat updates give them a chance to prepare for these changes at a time of their choosing.

Of course, you need an extensive battery of unit tests and integration tests, and lots of user testing in beta. But actually if you're only deploying smaller self-contained changes then there's less moving parts at any given time. You'll have stronger guarantees of less interactions.

https://support.mozilla.org/en-US/kb/choosing-firefox-update...

Short release cycles mean smaller deltas and it also makes postponing the merging of changes to the next release is less disruptive. Merging things when they are ready instead of merging them to early to not miss some big releases is better.

Another reason smaller deltas is better is that risk does not scale with a linear relation relative to the amount of change but more like a quadratic or exponential relation. So, the less changes you introduce with a release, the less effort you need to ensure all is well. The testing over head increases massively with the amount of change since there are more combinations of things that can go wrong that all need testing. Finally, with the time increasing between the introduction of issues and people finding them, the complexity of analyzing them in the presence of other bugs becomes harder. Shorter feed back cycles are great for finding issues early.

Currently from nightly to release takes about 12- 16 weeks (assuming 6-8 week cycles). With this change, it will reduce to about 8 weeks. That's still two months of exposure to large group of nightly testers and an even larger group of beta testers.

Uhh really? Pretty sure "most people" don't even notice when their browser updates.

Furthermore, the audiences for each of these channels are different, with Nightly being much more tech centric early adopters. While you do some testing in the prerelease channels, you main experimentation is going to have to wait until the code hits release.

So, let's say a feature takes 7 weeks to properly build and test. You start on week 1.

Now, after 6 weeks, a release goes out. A week later, your feature is done. You now have to wait 5 weeks before your release goes out. So, you merge your feature and move on to your next feature. 5 weeks later, your features is released.

So, to release a feature that takes 7 weeks, you had to wait 12 weeks.

Now, with a 4 week release schedule, you only have to wait 1 week.

This is a bit simple, but it really works this way. Now, here is the other end of the spectrum.

Let's say the release schedule is once every 12 weeks. (Under the idea that quicker is worse and slower is better). Now, let's say at week 6, you start your 7 week feature. It will get done on week 13, and have to wait 11 weeks to get released. That's a long time! So what happens? Well, what tends to happen is people push to get it done in 6 weeks rather than 7. That means skipping steps, working longer hours, and cutting corners. Why? Because they don't want to finish with something and have to wait 11 weeks for it to get released. They want to get it out there.

However, if you know that the longest you have to wait is 4 weeks, that's a lot more palatable.

> And features requires time to think, design, bake, tested in real world and refine,

Having more frequent releases doesn't change that.

> having a few more releases in between those process doesn't make the features come out any quicker.

tl;dr: They don't make finishing the feature faster. But they do allow finished features to get released faster. =)

https://www.mozilla.org/en-US/firefox/enterprise/

The shortcuts I use work fine, so I don't understand the complaint.

I'm guessing this is not the case, because the demands and requirements of browsers would have increased massively since then in terms of the breadth of the developer APIs and security issues that need to be dealt with, plus an every increasing demand on speed and having the largest company in the world with effectively unlimited cash, the best minds and some sharp practices as your competitor.

You're presenting a very naive and romanticized version of the story.

source: I've been involved in Phoenix since 0.2.