19

Possible Duplicate:
What “version naming convention” do you use?

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.

Which one would you choose for your project and why?

Community
  • 1
ef2011
  • 301
  • 2
  • 6
  • 2
    Good question. If older clients wish to receive patches rather than the latest and greatest, then the whole date-based build numbers start to fall apart. – Job May 19 '11 at 20:44

10 Answers10

31

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.

sange
  • 892
  • 6
  • 9
  • 2
    @sange Excellent point regarding the users/clients. +1. – ef2011 May 19 '11 at 19:24
  • 12
    +1: [YYYY].[MM].[DD].[hh][mm] has no **meaning**. It's just a coincidental binding between a moment in time and a release. – S.Lott May 19 '11 at 19:41
  • @S.Lott Yes, I agree. – ef2011 May 19 '11 at 19:45
  • 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. – rwong May 19 '11 at 19:52
  • 2
    Here is a good resource for [Semantic Versioning](http://semver.org/) – Thomas James May 19 '11 at 21:07
  • Date-based also fails if you have more than one version being supported. How do you date-stamp version 4.0.0.1 (a bug-fix release) when 5.1 is the current version of your software? –  May 20 '11 at 00:52
29

Why not combine them:

[major].[minor].[YYYYMMDDHHMM]

That way you get an easy way of showing the version (the available feature) and additionally a method of seeing when it was built.

This method also allows you to have two different versions out in the field (Ver 1/Ver 2) simultaneously.

Martin York
  • 11,150
  • 2
  • 42
  • 70
  • @Martin Great idea. I have seen some companies adding "build number" instead of the timestamp. Which one is better? – ef2011 May 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.) – Charles May 19 '11 at 19:42
  • 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. – Martin York May 19 '11 at 19:45
  • 1
    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. – quentin-starin May 19 '11 at 19:55
  • or `[major].[minor].[unixseconds]` :P. – crazy2be May 20 '11 at 00:02
  • @Martin proper use of version control makes it easy to find out what changed in either case. – Rein Henrichs May 20 '11 at 04:13
  • @Rein Henrichs: 6 of one half a dozen of the other. Can;t really justify why I prefer the time-stamp but the same can be said for the other side. Did we fix the security hole to the hyper-drive by build 37482, or is it easier to remember that we fixed the security hole in the hyper drive by May 19. When your not in front of the computer (i.e. meeting) I know which I prefer, in-front of the computer its identical in their usage patterns. – Martin York May 20 '11 at 05:25
11

http://semver.org

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.

Semantic versioning helps set and maintain expectations.

gnat
  • 21,442
  • 29
  • 112
  • 288
Rein Henrichs
  • 13,112
  • 42
  • 66
5

[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.

SLoret
  • 565
  • 2
  • 9
  • Thanks. Is there an Eclipse plugin that generates build numbers automatically for Android app development (modifying the Manifest XML file automagically)? – ef2011 May 19 '11 at 19:36
  • @ef2011 I don't know, never looked for one. – SLoret May 19 '11 at 20:41
4

It depends on the type of project.

Versioning with a timestamp generally works well for web applications, where there is only one live copy of the code deployed.

Versioning with Major.Minor.Revision generally works better when you must manage several simultaneously deployed versions.

quentin-starin
  • 5,800
  • 27
  • 26
2

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.

Steven Evers
  • 28,200
  • 10
  • 75
  • 159
  • 1
    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. – rwong May 19 '11 at 19:48
2

major vs minor vs revision isn't subjective, it is pretty straight forward.

revisions are bug fixes or tweaks,

minor are additions and changes that don't break existing APIs or behavior,

major breaks API or adds features that change how the existing version works.

These are empirical cases and not subjective at all.

  • Who decides whether a new feature warrants a `major` or `minor`? The programmer? The manager? The sales person? The PR firm? The customer? – ef2011 May 19 '11 at 19:47
  • read what I wrote on why you pick one or the other, it is empirical, –  May 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 Mittag May 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 Mittag May 19 '11 at 23:25
1

I personally would suggest [major].[minor].[revision].[YYYYMMDD] I am not exactly sure the reason you need the hour and minute it was built :$

Ramhound
  • 871
  • 8
  • 12
-1

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?

Juha Autero
  • 59
  • 1
  • 1
-1

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:

  1. 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.

  2. 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.

C. Dragon 76
  • 119
  • 2