Software Bugs, Software Releases and Version Numbers

Occasionally the inevitable happens and I get a problem report on my software products. Usually this doesn't happen frequently, e.g. for the whole of March, April and May 2008 I haven't had a single problem report.

When a problem is reported I have to weigh up how serious the issue is and how many customers are likely to be affected. In one sense all customers could be affected by a software bug, the question comes down to how many people are actually likely to run into the issue.

One thing that helps is how long a software release has been in distribution before the problem is reported. If the release has been in the field for a few weeks - or hopefully months! - I can have more confidence there's no need for a knee jerk reaction. If this is the case I can avoid a global release to all registered customers.

Whatever happens, if a customer has reported a problem I will either try to find a workaround that we are both happy with or provide them with a new software release. I do this whether or not the customer has paid for an unlock code or is still using a trial copy of SliQ Invoicing and Quoting.

If I make a special release for a single customer I use an intermediate version number for my products. Normally I use 3 digits to number software versions. For example:

1.3.0

1.3.1

1.4.0

but if I do a release to a single customer I will use a 4th digit on the version number in the application's software version resource. For example:

1.3.1.1

if a problem was found in version 1.3.1.

This way, when I come to do a full public release of software, I can avoid documenting the intermediate versions in the Release History on the product website. I can just document the major, public releases: 1.3.0, 1.3.1, 1.4.0

Of course, one question will always be: what's the difference between a bug and feature that doesn't work the way a customer expects? This is a topic for a different post however.