Policy on maintenance releases vs normal releases?

Question

My company is struggling with the question of maintenance releases versus "normal" releases, in the context of an application installed on-site at large organisations who pay for support. First let me define my terms:

• Imagine we've released versions 1.0, 1.1, and 1.2 of the product. These are what I call "normal" releases, i.e. they are the next release from the main branch of development, incorporating all the latest and greatest bug fixes and enhancements (possibly tens of each per release).
• Now imagine some bigshot customer on 1.0 reports a show-stopping issue that nobody's encountered before. The problem still exists in 1.2, and unfortunately 1.3 isn't due out for several weeks or months. So we branch our code at 1.0 to create a 1.0.1 "maintenance" release, containing just the one change that fixes the issue.

This approach makes the customer happy because we fix their issue within a day or so, instead of making them wait weeks until the next normal release. Also, because the maintenance release only contains one small change, they don't need to go through an extensive UAT process, whereas if they upgrade to the next normal release, which could be several versions on, they would be receiving maybe 30 or 40 product changes that (in their risk-averse opinion) require extensive UAT.

The problem is that:

• It's costly for us to create and support multiple versions of our software
• It allows stick-in-the-mud customers to fall too far behind the latest version
• It complicates the process of eventually upgrading those customers in the future, as their installation is subtly different from every other 1.0 customer (upgrading their database is particularly complicated if the maintenance release changed it somehow)

So I was wondering what is everyone else's stance on this issue? How do you keep the customer happy without making a rod for your own back through a proliferation of maintenance releases? For example, do you allow some categories of fix to be done as a maintenance release, but insist that other types are done in the next normal release?

Clarification: writing bug-free software isn't a total solution, because an "issue" in the above context could be an unforeseeable change to the behaviour of an external system upon which our product depends.

Answer 1

I suggest reading Version Control for Multiple Agile Teams and especially the Release branches section (what works for N teams works for 1 team too).

From what I've read so far in the various answers and comments, you might find some good advices in it.

Answer 2

Unfortunately, this is the kind of thing you need to have decided before signing any contracts with your first customer. If it isn't in the contract, it doesn't exist.

For shrinkwrap, you should not care. There is no contract so you have no obligation to provide any support. Regardless of the desire to maintain good relations. Fact is, you have already gotten your money from the past customer. Supporting them in perpetuity will cut the profits already receive to nothing in no time. If you really want to move to a service model, you can't sell the software in shrinkwrap. (Think about Anti-virus software. You stop paying, they stop updating.)

Give a list of dates on your website for when you will stop support of past versions and stick to it. If they don't like it, they can look for new software. You were never guaranteed future sales.

EDIT, in response to comment: Then, as I've said your problem is your contracts. If they don't give you the power to say "you must upgrade" or "we don't support more than the last three minor releases" then your company is screwed. Going forward, you should make sure your future contracts do include such language. Ongoing Support only means what the contract says it means.