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 cycle projects and shorter cycle projects.
Firefox has been on a 6 weeks cycle for a few years now, clearly they found that short release suited them, and that it was if anything too long. Different strokes and all that.
It's not like features go straight from master -> release in 4 weeks. Changes have to go through developer-edition and beta channel first before landing in the release channel.
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.
Generally speaking, you can release based on the calendar or based on whenever you think the feature set warrants it. You are advocating the latter which works well on low traffic projects. The former is a better idea on high traffic projects where there's always something worth shipping whether it's a new translation, a bug fix, or new feature.
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.
Because regular, predictable releases mean that developers know they can always "catch the next train", and users know they can plan around predictable upgrade schedules.
> Because regular, predictable releases mean that developers know they can always "catch the next train"
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.
Is "releasing when it's ready" basically what was done in the past for e.g. CD-distributed software?
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.
Firefox ESR exists for exactly this reason. It gets periodic security fixes but not much else and you can stay on the same major version for a year or so. https://www.mozilla.org/firefox/enterprise/
Notice that almost all the positives of quick release cycles are about how they make it easier for developers? I think is telling of where tech culture is these days.
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.
Fortunately I don't do family tech support anymore, but that's exactly the sort of thing that would result in a panicked phone call and a user having to "learn it all over again". And that's for a purely cosmetic change.
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.