Version Numbering Philosophy

This page has been deprecated. Please see ZipTieReleaseVersioning for the latest on our release versioning philosophy.

The Main.ZipTie version numbering scheme is based on Ubuntu and Gentoo's "versioning model". Because we are an open source project, there is little motivation to engage in "version number wars" such as occur often in commercial software development.

From Wikipedia http://en.wikipedia.org/wiki/Software_versioning:

Keeping up with competitors
There is a common habit in the commercial software industry (usually, though not always, spurned by non-commercial programmers) to make major jumps in numeric major or minor version numbers for reasons which do not seem (to many members of the program's audience) to merit them: "marketing" version numbers.

In addition, the Wikipedia entry describes a (surprisingly) large number of versioning schemes. Some of these include odd-even numbers aka development/stable (Linux kernel), major.minor.bugfix, etc. Out of them all we think the Ubuntu and Gentoo versioning models make the most sense for open source.

There is a growing movement in the industry away from classical major.minor versioning. For example:

• Microsoft has abandoned across their entire product line in favor of simple product names (XP, Vista) or years (Office 2007).
• Apple has settled on OS X (in this case X meaning 10), but rather than the "next release" being 11, or 12 as they used to do (remember Mac OS 8.6 and OS 9?) they now only use the digit right of the decimal for major versions so that they can keep the X (for marketing reasons). So, the current version is 10.4 and the next version is 10.5. Interim releases use a further decimal, eg. 10.4.9. However, they actually prefer to refer to their OS revisions by code-name, i.e. Tiger, Jaguar, Leopard.
• Sun has over time gradually transitioned Java from a major.minor model (1.1, 1.2, 1.3) to a "Big number" model, i.e. Java 5, and Java 6. Technically "Java 5" is version 1.5, but this is downplayed and even more so with the marketing around "Java 6".

The ZipTie Scheme

The "Ubuntu model" is so simple it is easy to dismiss. Software is simply versioned according to the year and month it is released (i.e. year.month). More specifically YY.MM dropping leading zeros but keeping zeros trailing the decimal, for example 7.06, 7.11, 8.02 representing June 2007, August 2007, and February 2008 respectively. The first release of Ubuntu ever was version 4.10.

The "Ubuntu model" of versioning takes all of the guesswork and more importantly arguing and politics out of the versioning process. When using a major.minor.bugfix scheme there are inevitably disputes over what constitutes a "major change". Early in the life of a software project almost everything is a major change. Many open source projects have gotten the major.minor.bugfix model wrong and as a result have taken bad publicity beatings from their users (and developers!). The Ubuntu model not only avoids internal disputes over version, it sidesteps publicity beatings.

As a consequence of the Ubuntu versioning model you don't really know what the "next version" is until you get there. Therefore, Ubuntu works off of code-names for releases ("Breezy Badger", "Feisty Fawn", etc.), or alternatively by adding a plus sign (+) to the existing version, i.e. 7.06+. Code-names are common practice even for classically versioned software (major.minor.bugfix) as the final decision on version is often delayed until near the end of the development cycle. In the Ubuntu model it is more central as all discussions are framed in the context of the upcoming release name rather than version.

See the Ubuntu FAQ for a discussion of versioning: http://www.ubuntu.com/aboutus/faq

At ZipTie we decided to modify it slightly by including the four digit year (yyyy.mm) to remove any amibiguity from the release versions.