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?

Improve this question
1
  • 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, 2011 at 20:44

10 Answers 10

Reset to default
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.

Improve this answer
7
  • @Martin Great idea. I have seen some companies adding "build number" instead of the timestamp. Which one is better?
    – ef2011
    May 19, 2011 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, 2011 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, 2011 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, 2011 at 19:55
  • or [major].[minor].[unixseconds] :P.
    – crazy2be
    May 20, 2011 at 0:02
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.

Improve this answer
6
  • 2
    @sange Excellent point regarding the users/clients. +1.
    – ef2011
    May 19, 2011 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, 2011 at 19:41
  • @S.Lott Yes, I agree.
    – ef2011
    May 19, 2011 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, 2011 at 19:52
  • 2
    Here is a good resource for Semantic Versioning
    – Thomas James
    May 19, 2011 at 21:07
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.

Improve this answer
1
  • +1. Semantic versioning removes the subjectivity from [major].[minor].[revision], I use it all the time now.
    – Michelle Tilley
    May 19, 2011 at 22:38
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.

Improve this answer
2
  • Thanks. Is there an Eclipse plugin that generates build numbers automatically for Android app development (modifying the Manifest XML file automagically)?
    – ef2011
    May 19, 2011 at 19:36
  • @ef2011 I don't know, never looked for one.
    – SLoret
    May 19, 2011 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.

Improve this answer
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.

Improve this answer
1
  • 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, 2011 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.

Improve this answer
4
  • 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, 2011 at 19:47
  • read what I wrote on why you pick one or the other, it is empirical,
    – user7519
    May 19, 2011 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, 2011 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, 2011 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 :$

Improve this answer
2
  • 5
    Hours and minutes are helpful if you build multiple times a day.
    – Adam Lear ♦
    May 19, 2011 at 19:29
  • HHMM might be good for QA or something, but are probably not useful for clients, unless it was released multiple time a day.
    – Bratch
    May 19, 2011 at 20:24
-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?

Improve this answer
-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.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.