404 Tech Support

When it comes to version numbers, the most important thing is to pick a system

If you write enough scripts, eventually you will need to update one to fix a bug or introduce a new feature. How do you keep track of which version of the script is out there? You add a version number to your product. If you look around the web, there are plenty of ideas on how versioning should work. It’s best to consider your environment (version control software) first and then pick a system that works for you. Many of them can feel pretty arbitrary as some count the number of changes implemented and others try to estimate the significance of those changes. It’s not like the next version after 0.9 becomes 1.0 rather than version 0.10. I mean, unless you’re Firefox trying to catch up to Chrome.

Some developers will incorporate the date (like month and year) to designate the version while others will use “point” releases to divide between major and minor releases, down to maintenance releases and builds. The latter is a common system with each decimal indicating Major release, minor release, maintenance release (like a bugfix), and optionally the build number or a number specific to source control. The system I have adopted is a point release system.

A.B.C.D

A = Major change (a complete rewrite or adding a GUI to a script, a change the clearly distinguishes this version)
B = Moderate change (adding or removing a significant feature or functionality)
C = Minor change (a significant bug fix, or adding, removing, or changing a minor feature or functionality)
D = Service change (a small bug fix or insignificant change)

In this system, the biggest change denotes the change in version number. For example, adding a significant feature would change a script from its current version of 1.2.1.0 to 1.3.0.0. The minor bug fix that follows would bring it up to 1.3.0.1

This is a system that works for my scripts as they’re pretty simple but it has room to grow for complexity though it may not satisfy everything that a more formal development needs. The most important thing is to pick a system, document it, and implement it.

You can see a variety of existing schemes on the Wikipedia page for Software Versioning and a lot more thought on the topic from the Semantic Versioning site.