Earlier quoted context omitted.
What's broken with keyboard shortcuts?
Not being able to configure them would be one thing. The lack of a shortcut to open reader mode for years another.
Cmd + alt + r
Firefox moving to 4 week releases
31–40 of 195 posts
Re: Firefox moving to 4 week releases
#32According to my calculations, this means Firefox 100 will be released on 2022-03-08.
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 :(
Re: Firefox moving to 4 week releases
#33For comparison, Chrome updates "every two-three weeks for minor releases, and every six weeks for major releases". I guess Beta is moving to daily releases? I suppose it's good, generally I have to restart Firefox once a day for resource leaks and restarting through the update UI is easier than opening the browser console. I was using Nightly for a while but it turns out that even daily updates aren't fast enough for…
[deleted]
Re: Firefox moving to 4 week releases
#34As 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.
Re: Firefox moving to 4 week releases
#35> In recent quarters, we’ve had many requests to take features to market sooner. Surely not from the users. > Feature teams are increasingly working in sprints that align better with shorter release cycles. Poor guys. At least the process “guarantees” long term quality as the result. > Shorter release cycles provide greater flexibility to support product planning and priority changes due to business or market require…
> I’d prefer more stable, less CPU and battery hungry browser than one that shovels to my desktop the newly decided features from the marketing as soon as possible. But it’s just me.
Patches welcome.
Re: Firefox moving to 4 week releases
#36As 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.
No you don't. You had automated updates before, and you'll have automated updates now. Same with Chrome.
Re: Firefox moving to 4 week releases
#37> In recent quarters, we’ve had many requests to take features to market sooner. Surely not from the users. > Feature teams are increasingly working in sprints that align better with shorter release cycles. Poor guys. At least the process “guarantees” long term quality as the result. > Shorter release cycles provide greater flexibility to support product planning and priority changes due to business or market require…
> Surely not from the users.
I'd love for the recent changes to rendering which fix long standing performance issues on OSX to hit release as soon as possible. https://twitter.com/whimboo/status/1168437524357898240 . Many users are running nightly right now to take up these changes because they are so valuable. As a user, I'm requesting Firefox take features to market sooner :)
> Poor guys. At least the process “guarantees” long term quality as the result.
Philosophical question: does letting code incubate for a longer period of time with the same test/user load (same nightly/beta users, same integration test suite) really enhance stability?
> Translation: marketing managers want to change their minds faster than up to now.
This is just blanket cynicism - do you have insight into the Firefox development process that suggests this is true?
Re: Firefox moving to 4 week releases
#38I think this is sad news, but that's because I view the current "rapid release" trend and being, on the whole, a bad thing for everyone. It decreases software quality, decreases stability, and increases hassle and stress for everyone from developers to users.
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.
Re: Firefox moving to 4 week releases
#39As 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.
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"
Re: Firefox moving to 4 week releases
#40According to my calculations, this means Firefox 100 will be released on 2022-03-08.
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.