Should've kept the major at 69 and started incrementing the minor only, forever. The browser must be nice! :D
Firefox moving to 4 week releases
41–50 of 195 posts
Re: Firefox moving to 4 week releases
#42Earlier quoted context omitted.
If releases are painful, then something is wrong with your development cycle and deployment process. If you spend the effort to make it painless, then it makes no difference whether releases are 6 weeks or 4 weeks. 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…
You're addressing the pain for the developer but not the pain for the user and society more largely. The user (who may be on a slow internet connection) has to deal with the bandwidth of the more frequent downloads. Society has to deal with additional network congestion costs and electricity usage.
True, but by using binary deltas you can minimize that cost. And failure to upgrade may mean running more inefficient algorithms, wasting more processor cycles, or transferring more data in general. For instance, if you are on a browser that doesn't support Brotli compression then you'll miss out on the dramatic compression improvements provided by that algorithm.
Re: Firefox moving to 4 week releases
#43> We’re adjusting our cadence to increase our agility, and bring you new features more quickly. In recent quarters, we’ve had many requests to take features to market sooner. Mozilla has been tweaking their process forever, but all of it is for naught if they don't work on what users want. The latest FF brags "we are shipping a new “New Tab” page experience that connects you to the best of Pocket’s content", while st…
What's a concrete example of a broken shortcut? The shortcuts I use work fine, so I don't understand the complaint.
Some shortcuts I use -- like Alt-$NUMBER to jump to a specific tab -- are frequently overridden by websites, which I view as a browser breakage because this should simply not be allowed.
Re: Firefox moving to 4 week releases
#44Earlier quoted context omitted.
A faster release cycle done right mean fewer features are added per release -- you are releasing 4 weeks of engineering work instead of 8 weeks or whatever. This can make bugs less likely if done right. It also makes it a lot easier to react quickly to bugs that do get released, and if you have to roll back you are rolling back fewer new features.
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?
Given Mozilla's track record of stability even for Nightly releases, I'd expect it to be done right.
Re: Firefox moving to 4 week releases
#45Earlier quoted context omitted.
No you don't. You had automated updates before, and you'll have automated updates now. Same with Chrome.
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.
Re: Firefox moving to 4 week releases
#46I'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?
Re: Firefox moving to 4 week releases
#47I'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?
I think it's more a matter of discipline than anything else. It's easy to get lost in the weeds with a ton of things waiting to be merged, and over and over saying "just one more PR to merge and then I'll release", and then it's a year later and you still haven't released.
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.
Re: Firefox moving to 4 week releases
#48Earlier quoted context omitted.
A faster release cycle done right mean fewer features are added per release -- you are releasing 4 weeks of engineering work instead of 8 weeks or whatever. This can make bugs less likely if done right. It also makes it a lot easier to react quickly to bugs that do get released, and if you have to roll back you are rolling back fewer new features.
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 4 weeks, a missed release is not as big a deal.
2) Long release cycles means things done early in the release get forgotten, so when it's finally released, they tend to be off people's minds.
3) Larger releases become harder to update and deploy. Larger file sizes, a lot more changes all at once.
As someone who has done both (long and short release schedules) I can't imagine going back to long release schedules. It has a lot more complexity and is a lot more error prone than a shorter release schedule. Not only do you get the practice, but people are more inclined to wait until next release to get it right.
Re: Firefox moving to 4 week releases
#49I'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?
Firefox probably had bad memories of when they "released when it's ready" during the FF3 -> FF4 days where a couple of features held back everything. With fix released cycles, they have more of a motivator to cut off things that aren't ready yet so that the things that are can go out.
Re: Firefox moving to 4 week releases
#50Earlier quoted context omitted.
In general I like more the classic/old way of versioning the releases, like for example "1.2.2" which has some embedded meaning of what is changing (e.g. . . ) which hints at how potentially dangerous an upgrade might be or if some new exciting stuff has been included. Jumping directly from 10 to 11 to 12 leaves me clueless without reading all release notes :(
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