[kerkeslager]

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.

[fnord123]

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.

[JoshTriplett]

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.

[kerkeslager]

> 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.

[slimsag]

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.