How often should you release software updates? [closed]

Question

Moments ago Jeff Atwood said the following on twitter:

Look, I love rapid new software releases, but the frequency of WordPress releases is just ridiculous.

Which makes me think, how often should you release software updates?

• Daily?
• Weekly?
• Monthly?
• Yearly?

Whats the best release strategy?

Answer 1

I would say in WordPress' specific case, they conflate "security updates" and "functionality updates". This is bad.

This would be like having to do an in-place reinstall of Windows every time a security bug was found, instead of simply downloading a small patch every week.

WordPress needs to have a security patch mechanism that's simple, fast, and easy for the security updates. A process that is separate from the normal upgrade flow of new versions.

Answer 2

The frequency of Wordpress releases is so frequent because they care about security and release updates that fix known vulnerabilities as quickly as they can. Functionality updates to Wordpress happen much less frequently, in the range of every 4 to 6 months I think.

I think this is a good model. Keep your customers happy by releasing new features regularly, but if you find security flaws, release fixes immediately.

Answer 3

I'll suggest the following:

updateTime (in seconds) - the average time it takes for the user to perform the update

releaseDelta (in days) - the minimum time between releases

releaseDelta = updateTime/((1/365)*(60*60*8))

This formula is based on my theory that a user should have to spend no more than 8 hours in any given year waiting for updates to an application.

This also allows for frequent updating as long as the updates are done in a transparent manner without disrupting the end user.

Answer 4

I think this highly depends on your particularly situation. That being said, I think a daily release for any serious business application just totally ludicrous. If you are releasing every day then there is probably a serious problem unless you are in some very strange situation where business rules change constantly or something like that.

Answer 5

Less frequently than iTunes updates.

Answer 6

I try to use the following, hopefully simple, two-part guideline:

1. If it requires the user to download and/or install something, or change an existing codebase that they maintain, then releases need to provide significant merit. This is a release that adds significant new features, fixed a significan amount of issues, or fixes a smaller number of immediate and pressing issues.
2. If it does not require the user to download and/or install releases will be planned to occur, as dictated by iteration. If there is a releasable product at the end of the iteration, it will be deployed. The iteration will contain technical and business needs as determined prior to the kickoff of the iteration.

So, for us, things like desktop applications or web services would generally fall under the first rule, and things such as our web site would fall under the second. We run fairly good sized iterations - at about four to six weeks of development time currently, decreasing to two to four next year. This was our "introduction" into a Scrum-hybrid.

Note that a product doesn't always have to be in development (or participating in an iteration). It is quite possible that a product will sit, stale, until changes are needed if the first rule applies.

Answer 7

It depends on the customers approach to configuration control.

They have a choice, you know. Ultimately they can chose not to use your product.

If the customer will accept you changing stuff every day, and they don't care, and it has no training or configuration management impact; have automatic updates.

Customers with SOE ( Standard operating environments) hate updates.

Realize that some customers are not going to accept software "calling home". They will want to host their own updates. Their IT people will have to get involved. This is more work for them.

Some customers will want/need to do their own QA; depends on the customer and the kind of software.

If the customer needs to do testing/work to accept/deploy the software, release some multiple of the length of the test/deploy cycle. Unless the customers are okay with interleaved deploy and test. That's where they are always testing a new version, and the roll it out.

For example: 2 weeks to test, release not more than every 8 weeks.

In result critical software, release testing may take a customer months. They are betting their business on the results and are justifiably cautious. So releases are every 6 months or so.

In safety critical software, it may take MANY months. Annual, or about every 18 months is not uncommon. Even less often is quite normal.

Answer 8

There is no right answer, it really depends on the product.

I say monthly at most. Weekly/Daily is just too often, unless of course the application updates are done in a automated and transparent way, e.g. Firefox's update system

Answer 9

You can release them as often as you want. The thing that frustrates users is not knowing whether they need your new version or not. This means that you need to be very clear about which new features you've implemented, the bugs that you've fixed, and whether or not you've fixed any security issues. More importantly, your users want to be able to trust that, if they do install a new version, nothing got broken.

Answer 10

I think that if it's possible you should have your software update automatically when it needs to, so as to keep the whole update process as smooth and invisible to the user as possible.

Answer 11

For the area I work in, Industrial controls, very seldom. We typically do a major release very 2 years. Minor releases maybe every 3 to 6 months. Bug patch are of course a different story, they are released as needed. Even then few customers will upgrade existing systems. Of course in other domains, upgrades are more accepted.

Answer 12

Surely when you have new features/bug fixes worth releasing ?? Why have it on a schedule ?

Answer 13

I have no objections to security bugs getting fixed as soon as they're found - although I wish they'd write more robust code in the first place. What I object (at least as far as Wordpress goes) is enhancement releases that could potentially break plug-ins happening too quickly. How long did it take to go from 2.5 to 2.6? And 2.7 is coming out very shortly as well.

An automatic or semi-automatic upgrade would mitigate some of that problem, but only if plugin writers upgrade as well, or if they separated security fixes from functionality changes so I could, say, stick with 2.5 but still be up to date with the security patches until I was sure all the plugins I use work with 2.6 or 2.7 or (by that time) 4.0.

Answer 14

Whenever they are required. Keep in mind some users feel more secure getting updates regularly, while some just feel annoyed having a pop-up every day "There are 129 new updates to install! click here to wait 20 minutes to download, then another 10 to install them!"... you see my point.

Answer 15

It depends on the nature of the upgrade and the amount of user intervention necessary to accomplish it.

If it's a web site, you can upgrade every day, as long as you don't break anything.

If it's a free security update, ASAP is always appreciated.

A free bugfix upgrade, if it has to be installed by the user, shouldn't be more than every couple of months.

Anything that has to be paid for can't be more frequent than once a year, or people will start to feel taken advantage of. Even more for certain classes of software, such as operating systems.