Live data from Hacker News

Firefox moving to 4 week releases

hacks.mozilla.org

81–90 of 195 posts

Re: Firefox moving to 4 week releases

#81

I don’t really like these quick release cycles. When things get released every year or half year I have the time to read about the changes but if I work with several packages that release all the time I don’t even have the time to read about the changes. I also think that quality tends to suffer. Over the last two years windows 10 has released several buggy updates that caused our in house apps to stop working.

> I don’t really like these quick release cycles. When things get released every year or half year I have the time to read about the changes

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.

Re: Firefox moving to 4 week releases

#82

Earlier quoted context omitted.

Semantic versioning is useful. Unfortunately the marketers have taken over and there's a numbers race going on.

Semantic versioning is useful for libraries. Let useful for consumer apps. 2019-10 says more than 76.0.0

> 2019-10 says more than 76.0.0

Neither says anything useful. 2019-10 is no more actionable or informative than 76.0.0. That 2019-10 was released in october 2019 is meaningless information and only "more" in the "babble" sense.

Re: Firefox moving to 4 week releases

#83
post #67
post #45

Earlier quoted context omitted.

This isn't going to significantly increase the speed at which new features are developed, just the speed at which they're released. The overall risk of you encountering a new feature you don't like won't be higher.

Whoever spends some fixed amount of time evaluating the release will now spend more than 50% time than before. I’m one of those. If I’m only one of 200 (as in, 199 don't care) and if Firefox has 200 million users, Firefox will waste millions of hours of user’s time per each additional release.

Sounds like Firefox ESR is for you then.

Re: Firefox moving to 4 week releases

#84

Earlier quoted context omitted.

As you've said: done right. Done poorly, or even in a mediocre fashion, and we've got more half-baked features and insufficiently-tested changes. Now, which scenario is more likely?

If you are in a position to release every 4 weeks, then it doesn't matter. Release faster. A slower release schedule doesn't mean you have more testing time. It means you tend to release more in one feature. Further, because it takes longer to release, you run into a few problems. 1) People rush to get things into release because if they miss the release, they are waiting longer to get it out. If the release is every…

> A slower release schedule doesn't mean you have more testing time. It means you tend to release more in one feature.

Plus, most of the serious bugs are found right away when a new group of users starts testing, e.g. when Firefox Nightly version moves to Beta or Beta moves to stable Release. Firefox Nightly, Beta, and Release channels have very different user populations. They have different hardware (Nightly users are power users with big, fast machines), software (Release users are more likely to use anti-virus software or not have the latest GPU driver updates installed), and browsing usage.

Mozilla's studies of crash rates and bug fixes for Firefox Beta showed that most of crashes and bugs are seen in the first two weeks or so. Having more beta "bake time" with a very long beta cycle has little benefit after the first batch of bugs are found and fixed.

An interesting historical tidbit: about 60% of Firefox Beta users are in India and Indonesia. That is definitely not representative of Nightly or Release user populations! The apocryphal story is that many years ago, a local computer retailer started passing around copies of a beta CD of Firefox 4 so people didn't have to download it over a slow or metered internet. And then all those people are still on the Firefox Beta channel.

Re: Firefox moving to 4 week releases

#86

As a user I also now need to keep up with the updates more frequently. Either deal with a more frequent risk of getting an update I don't like, or get nagged more frequently with annoying pop-ups to update if I don't want to, or turn off everything and miss out on the critical security updates.

Just switch to ESR if you don't want constant updates?

Yep, this is exactly the reason they exist.

Re: Firefox moving to 4 week releases

#87
post #46

I've always wondered this: why release on a schedule at all? 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? And why does this have to increment the major version, since when is every single update backwards incompatible?

This is a great overview of different release management strategies and the practical implications: https://www.youtube.com/watch?v=IKsQsxubuAA

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...

Re: Firefox moving to 4 week releases

#88
post #64

Earlier quoted context omitted.

Mozilla only provides binaries for Linux 32-bit, Linux 64-bit, macOS, win32, and win64: http://ftp.mozilla.org/pub/firefox/releases/69.0/ All of the various Linux distributions just repackage those binaries. iOS and Android are distributed only through the App Store and Google Play. The BSDs and other ("tier 3") platforms have to compile from source and distribute their own packages: https://developer.mozilla.org/en-…

> All of the various Linux distributions just repackage those binaries Debian and Ubuntu don’t build from sources?

They do.

You can notice by looking at the build time in the version string.

This makes it impossible to share a profile between two GNU/Linux distributions (or even the official binary and the distribution binary) without hacking with the current versions, even if they are effectively the same version: one will complain that the profile has been run with a more recent version.

(But I sure expect and want my distributions to rebuild Firefox - I trust Debian for making sure no bit of proprietary code is here, and makes tracking opt-in, more than Mozilla)

Re: Firefox moving to 4 week releases

#89
post #45

Earlier quoted context omitted.

That is already addressed in the parent comment, "deal with a more frequent risk of getting an update I don't like"

This isn't going to significantly increase the speed at which new features are developed, just the speed at which they're released. The overall risk of you encountering a new feature you don't like won't be higher.

It's not necessarily the number of features but the process of preparing oneself for changes likely to be surprising, unpleasant, require workarounds or length research as to workarounds, etc.

Re: Firefox moving to 4 week releases

#90

I don’t really like these quick release cycles. When things get released every year or half year I have the time to read about the changes but if I work with several packages that release all the time I don’t even have the time to read about the changes. I also think that quality tends to suffer. Over the last two years windows 10 has released several buggy updates that caused our in house apps to stop working.

Quality can be worse in a long-time cycle project: - Engineers are motivated to slam their feature in, because if they miss the train the next one's not for 12 months. - You get one moment per year to connect with your customers & understand how well/not well your changes worked. This means either riskier things happen or that innovation slows to a crawl. My 2 cents, speaking from some experience working on long time…

Why cycles at all? Why not look at what features have been integrated, whether they make up a set that you want to release, and then release?

Neither long cycles nor short cycles make any sense. Some features take a long time to develop, some take a short time to develop. Sometimes features that take a long time to develop aren't user-facing enough to be worth releasing for, and sometimes a quick fix has a huge impact that's worth a release, like a patch for a vulnerability that's actively being exploited by a spreading malware. Features simply don't line up with a single length of time. The problem isn't long or short cycles, it's cycles.

Post reply on HN