And today we’re excited to announce that we’re moving to a four-week release cycle! 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. Feature teams are increasingly working in sprints that align better with shorter release cycles. Considering these factors, it is time we changed our release cadence.
I’ve been incredibly satisfied with Firefox for a long time now, and aside from a few hiccups along the way, I trust the team to handle a faster release cycle just fine.
I agree, although I appreciate some Devs might think that schedule is too hard to maintain.
For me as I mentioned in another thread, Firefox is moving in the right direction and they more they do to accelerate that progress the better, as long as they commit to swiftly fix any breakages, and breakages are bound to occur in a shorter cycle! They’ve done good work in the past, and they’ll do more good work in the future, I’m not going to write them off due to any recent period of poor form!
As a Firefox dev I don’t think we’ll have issues maintaining this schedule. The problem with the previous schedule is that it was long enough for people to try and crash-land last minute changes before the release. This was problematic as it didn’t leave enough time for testing. With only four weeks between one release and the next nobody should feel pressured in shipping a feature that is not fully mature if the next chance to do is less than a month away.
I would even have expected 4 weeks is much too long for that. Where I work we have 2 week releases, and the last two days are always full of last-minute attempts to get something in.
Will some Devs be distressed by the idea their works leaves somewhat unfinished, I know I would, but then again I work in intrinsically safe sensors so it’s best not to patch it up later!
That is nonsense. Such thinking will always exist no matter the schedule. You need better review and commit discpline to prevent that, or if the team is too big a lenient right to revert.
What is the right balance? Bigger teams are like the Titanic, they can’t be agile, fours weeks is the blink of an eye! Smaller teams don’t have the power to get any real work done on short cycles, so the release becomes so trivial it’s pointless and end users will just skip!
Out of all this, there is some merit in Caraibes suggesting that people move to the ESR. Maybe that’s the real plan, the motive is to get Enterprise off the short cycle stuff! It’s not something I’ve really thought about before but I’m going to look into it now, well at least next time a release causes me grief! But I’m lucky, I don’t have millions of users to worry about, just a few thousand, and only a fraction of them use Firefox!
What would you guys think of using Firefox ESR on the desktop?
I run it in Debian, but I mostly use Windows 10, with regular Firefox. There are small differences, but it doesn’t seem to be that big of a deal.
On Android I finally settled for Firefox Preview, as it is really much faster than regular FF. But I don’t like the layout. I just wish they would make it look like the regular FF. Also Preview doesn’t (yet) support add-ons…
So for small projects this means constant porting of firefox every 4 weeks. It takes about a month to get a build working when nothing gets upstreamed. (well that was prior to rust)
Webkit it is then.
Wrong way, that is just making things even worse.
Recent decisions by Firefox, such as forcing Cloudflare’s DoH DNS on everybody makes me doubt their role as stewards of the open web. I think their interests and focus changed along the way.
Between having DNS messed with and a Webkit monoculture I’d rather not lose DNS, it’s even more control taken from the user.