Unless you've never used any software, nor have been exposed to the computer then you would have never seen version numbers for applications both offline and online.
Software versioning is the process of assigning either unique version names or unique version numbers to unique states of computer software. Within a given version number category (major, minor), these numbers are generally assigned in increasing order and correspond to new developments in the software. At a fine-grained level, revision control is often used for keeping track of incrementally different versions of electronic information, whether or not this information is actually computer software. A version number is both helpful for both the users and the developers. Other key players that could also benefit from versioning are the product owners, project sponsors, testers and project managers. So what is in a version number?
There are various types of versioning that can be used, where all are useful in different ways it will be used. Some of the popular versioning schemes are as follows:
- numeric ( major.minor[.build[.revision]] or major.minor[.maintenance[.build]] )
- date (Wine 20040505)
- year of release (Microsoft Office 2003)
- alphanumeric codes (Macromedia Flash MX)
- TeX (since version 3, each release was towards the value of 3.14 or pie which denotes stability for every release)
- others
Each build incorporates the new fixtures added, minor fixes, plus the fixed bugs. By looking at the version number, you would automatically understand the way the product was built and know what to expect thereof. With good quality software, each would be attached to a version number wherein details of the software can be traced to documents and specifications.
Each release too will not mean that it is bugfree or the more ideal product release, but is just more of a stable and bigger and better product. It is a must that the known bugs as well as the corresponding features would be affixed to the certain version number. In order for this to work, there must also be a good system or software development process for this to actually work. Bugs found in the release must be well documented and not "quick fixed" in production stage.
Personally, I like to use the traditional numeric versioning system, though sometimes its easier to put a face in your release when you use a mixture of these schemes to your production build. Like Ubuntu, their releases become easier to pinpoint and that the addressing of bugs are easy because they have a bug ticketing system (Launchpad) and the releases have faces under the names of Toy Story characters.
I admire the products and applications that adhere to a strict versioning system, like Firefox and Ubuntu. I believe that versioning your releases would not only aid in easier code maintenance but also in transparency. Clients would know what to expect and even when to expect it. If your codes don't use versioning up to now, maybe its time to do so.