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.
My 2 cents, speaking from some experience working on long time cycle projects and shorter cycle projects.
that said I think 4 weeks is a real short release cycle. 3 months, so 4 releases a year -- one for each season. Would seem to strike a better balance.
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.
I imagine that could work well in some cases, but it also allows corporate bureaucracy and/or marketing teams to determine when things get released at larger scales and that might not be so ideal.
This is an argument for frequent releases, not regular, predictable releases.
> users know they can plan around predictable upgrade schedules.
I'm not sure this is actually how users plan upgrades.
The majority of individuals probably never turn off the auto-update flag. Planning doesn't enter the equation.
For organizations, my guess is that most organizations will try to build their upgrade process around security, but the reality will rarely be so clean. When I worked in IT we'd get computers into our shop that hadn't been updated. Period. We'd upgrade our provisioning images when there was a notable security patch, and besides that, we just would run updates on every machine every week at 2am Sunday night: that way it didn't interfere with users, but if something went wrong, we were on it with the full team first thing Monday morning. But if machines were turned off or whatever, they wouldn't run the updates. At no point did we ever even check the release schedule of a piece of software: the updates happened on our time, and theirs was irrelevant.
I didn't work in IT for very long, though, so someone with more IT experience should correct me if I'm wrong.
It depends on the project, but in larger projects the calendar approach means politics takes a back seat as no one can hold back the release if their feature hasn't been merged yet due to blocking issues. And it helps keep the change-set small, and hence lower risk, if you release more often.
Also, Firefox already has a nightly release stream. I use the Aurora stream which releases a few times a week and have almost never had an issue with this frequency. I don't think a monthly release cycle is going to be an issue.
It feels like they're just taking the piss when the life cycle of an extended support release is just 42 weeks.
Still a step in the right direction though.
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.