I am currently debating between the traditional versioning convention [major].[minor].[revision] and my own, almost whimsical, [YYYY].[MM].[DD].[hh][mm] for a new project I am starting.

I understand that [major].[minor].[revision] is probably the most popular versioning method on the planet and it is indeed pretty straightforward and reasonable, except that determining which changes merit the label "major", "minor" or even "revision" could be... subjective.

A versioning system based on a timestamp is purely non-subjective and guarantees uniqueness.

@Martin Great idea. I have seen some companies adding "build number" instead of the timestamp. Which one is better?
–
ef2011May 19 '11 at 19:26

1

@ef2011, that can only be answered if you have a thing that can become a build number. Build numbers are usually assigned as part of the QA process to identify a specific set of code. You can think of it as a tag in your source code repository (and sometimes it really is). If you don't have a QA team or a QA process, then usually the unique identifier provided by your source code repository is a suitable "build number." (This is especially true if there's nothing to "build," like if you're using a scripting language instead of a compiled language.)
–
CharlesMay 19 '11 at 19:42

@Charles Thanks++ for this great clarification.
–
ef2011May 19 '11 at 19:45

2

I have been at companies that use revision and others that use the time-stamp. I personally prefer time-stamp (as I find it less work to go from time-stamp to what changed between these two builds) but its just an opinion I would not go whole hog and say it was significantly better I know others the prefer a build revision number.
–
Loki AstariMay 19 '11 at 19:45

This won't work in some scenarios due to the integer size allocated for each part of the version. Often there is a upper limit of 65535, which yyyyMMdd alone would overflow.
–
qesMay 19 '11 at 19:55

I would choose the [major].[minor].[revision] system mostly because it lets the users/clients/etc. know how big of a change the new update is.

Some users/clients/etc. would not want to update to a new version if it is just a [revision]. They may want to wait for a [major] change. A [major] change could be a user interface change. A UI change, no matter how small, can be a huge deal to an end user.

You lose this capability with the [YYYY].[MM].[DD].[hh][mm] system. The users/clients/etc. will not know how big of a change it is unless they look at the update log.

Major revision is usually used to mark major incompatibility issues. For example, files saved from a new major version may be unreadable by previous major versions, unless saved with compatibility options. Minor revision indicates that data (files, databases, web services) are inter-operable, but there are functionality changes and/or API changes (the binary interfaces are going to be different) and therefore should not co-exist on the same computer; build number is for bugfixes only.
–
rwongMay 19 '11 at 19:52

In the world of software management there exists a dread place called "dependency hell." The bigger your system grows and the more packages you integrate into your software, the more likely you are to find yourself, one day, in this pit of despair.

In systems with many dependencies, releasing new package versions can quickly become a nightmare. If the dependency specifications are too tight, you are in danger of version lock (the inability to upgrade a package without having to release new versions of every dependent package). If dependencies are specified too loosely, you will inevitably be bitten by version promiscuity (assuming compatibility with more future versions than is reasonable). Dependency hell is where you are when version lock and/or version promiscuity prevent you from easily and safely moving your project forward.

As a solution to this problem, I propose a simple set of rules and requirements that dictate how version numbers are assigned and incremented...

I call this system "Semantic Versioning." Under this scheme, version numbers and the way they change convey meaning about the underlying code and what has been modified from one version to the next.

[Major].[Minor].[Revision].[Build] Use Release date to record date and time and keep it separate. Including the build number as part of the version lets you know exactly what is in production, testing, etc without having to think or look-up date and times and check-outs, etc.

Who decides whether a new feature warrants a major or minor? The programmer? The manager? The sales person? The PR firm? The customer?
–
ef2011May 19 '11 at 19:47

read what I wrote on why you pick one or the other, it is empirical,
–
Jarrod RobersonMay 19 '11 at 21:30

@ef2011: The acceptance tests. In other words, not only is it entirely objective, it's even automatable. Any change, no matter how small, increases the revision number. Any added acceptance test increases the minor number. Any changed, deleted or broken acceptance test increases the major number. Note that this means that if you never break backwards-compatibility, you will never reach 1.0.0 (which is a good thing) and if you break often during early development, your version numbers may explode. You may want to relax the rules during very early dev, and eventually do a 1.0.0.
–
Jörg W MittagMay 19 '11 at 23:19

As much as we programmers may pretend otherwise, version numbers are also a marketing device. A product which never reaches 1.0.0 will be perceived as immature, even though the exact opposite is true: never breaking back-compat is a sign of maturity. Likewise, skyrocketing version numbers may be perceived as an unstable product which requires constant upgrading. So, it makes (marketing) sense to not bump the major number even for back-incompat changes for early development where such breakage is expected. Likewise, it makes sense to do a 1.0.0 even if you never actually break back-compat.
–
Jörg W MittagMay 19 '11 at 23:25

Build numbering and versioning don't have to be the same. You can use [YYYY].[MM].[DD].[hh][mm] for the build system, just give the release branch a name of [Major].[Minor].[Revision] when you create it.

Agreed. Software release versioning is used to highlight breaking changes, version compability changes, functionality changes, or bugfixes. These do not correspond to the timeline at all. (Commercial software often have to be supported on multiple software releases, represented by parallel timelines.) On the other hand, build versioning (numbering) corresponds nicely to the timeline, as well as code revision.
–
rwongMay 19 '11 at 19:48

I like [major].[minor].[build], where major number is incremented when major incompatible upgrade is made, minor is incremented with every release (service pack, hotfix, security release) and build number is incremented with every build. I don't see the point of having more than 3 numbers in version number. Why would you want to skip numbers or be afraid of large numbers?

It really depends on your software and the platforms you're releasing it for. A couple of cases where you might prefer a traditional [major].[minor].[revision] versioning system are:

If you sell shrink-wrap software, your licensing policy might be tied to major/minor releases. For example, you might sell MyApp v2.0.0507 to a customer for $99 and include two-years of free upgrades to any future MyApp v2.X.X releases. That's a little trickier to do with timestamp versions.

In .NET, the CLR (or fusion) uses the assembly versions to help determine which version of a shared assembly to bind to. For example, if just released MyLib.dll v2.0.0507.0 and need to release a security patch, you would increase the [build] or [revision] numbers (eg: v2.0.0519.0 or v2.0.0507.1) so the CLR would (by default) bind existing application build against MyLib.dll v2.0.X.X against your new service pack release. If you increase the [major] or [minor] fields, the CLR would assume it's a new release and not to bind old applications to it.