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

We create only one release for our customers, and we do daily build and unit test ( you do have both, don't you?)

With these two we can pretty much push out our code as frequent as we want, so there is no need to worry about maintenance release or normal release. There is only one copy that's worth using, and that's the latest copy.

Edit: When it comes to the situation "OMG our feature is half way but we still need to release it now and yes I mean NOW!" what we would do is that we would just tag the new feature ( by using preprocessor directive) and make sure that during the build, all the code inside the tag is simply commented out.

Answer 2

The customer comes first. You'll have to put up with supporting multiple versions of your software, because some customers just won't upgrade. It's an annoying fact of life. You can mitigate it somewhat in some areas of software development (e.g. webapps - anyone still running the original version of gmail?), but even in those sorts of thin client environments, people still won't upgrade the thin client (IE6 anyone?).

The best you can do is encourage clients to upgrade, perhaps by making updates automatic by default. If your clients feel a lot of UAT is necessary, it's possible you've upset them before by updates breaking things they rely on, and then fixes taking a while to come out. If so, look at improving your tests and QA process.

I'm not sure there's a lot else you can do to improve this sadly.

Answer 3

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.

Answer 4

we do have both maintainance and normal releases.

Suppose we are working on 5.5 release and the customer found some issues in the previous version may be in 5.4.0.1 we will provide them the solution in 5.4.1.0 and also make the modification in our current release i.e. 5.5 In this way we try to close the previous issues in the current release as well as provide a new kit to the customer in the old release

Answer 5

The following workflow might help you (but YMMV):

1. Create a topic branch for bugfix, branching it off at earliest point (e.g. 1.0 release), named e.g. 'foo-bugfix'
2. Create new branch for maintenance release for version e.g. 1.0, if it does not exist yet, and if bug exist in this version, named e.,g. 'maint-1.0'
3. Merge bugfix branch into maintenance branch, resolving conflicts if any.
4. Modify version number if needed. Tag new maintenance release, e.g. '1.0.1'
5. Repeat 2-4 for other versions that you want to support

Usually though you do maintenance release (on branch named e.g. 'maint' or 'maintenance') only for last version of project. However it is good practice, I think, if you find serious bug (e.g. serious security bug) to fix it on all versions that are affected (perhaps limiting yourself to versions that are not too old / are still quite widely used).

HTH

Answer 6

What I would suggest is to always ask the customer to at least try the latest point release: move from 1.0 to 1.1 to see if that solves their problem. First question asked.

What helps here is to make sure you put in no new features in point releases unless they cover a big functional hole in the software. Make point releases that are only intended for fixing bugs and at most for removing poor functional design. Save new features for funneling your customer into a repurchase of your product :-)

Not introducing new features with point releases may also lower your customers fear for new bug introduction; the reason why they are typically reserved when it comes to installing new versions.

If a customer still has the problem with your current point release and it's urgent he could get a 'hotfix'. If the current point release is 1.2, the hotfix may be included on the pre-release of 1.3 which is provided to the customer. This customer with an urgency is now actually helping you test your unstable point release and can also help provide feedback on some other changes in the point release. Doing a single fix small release that you merge back into the pending point release once your customer helped you test it is an option also.

This compares to Microsoft's service pack method: Release hotfixes often and then collect them together in a service pack (-> point release). Before wide release hotfixes are often tested together with customers facing problems the patch is out to fix.

What you definitely want to avoid is having a "1.0.1-customer A" and "1.0.1-customer B" you are inviting complexity and maintenance hell.

Normally you should always merge back your patches to your mainline. If your customer is helping your create patches for your latest version, then embrace it.

Answer 7

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.