Software developers don't typically use date as version number, though YYYYMMDD format (or its variances) looks solid enough to use. Is there anything wrong with that scheme? Or does it apply to limited 'types' of software only (like in-house productions)?

  • 5
    In some cases it could be ok, but that scheme doesn't handle well branches or patching old code. Take a look at the comments of this answer.
    – MikMik
    Commented Jan 19, 2012 at 12:07
  • 8
    Do you mean like in Windows 95 or MS Office 2010?
    – mouviciel
    Commented Jan 19, 2012 at 13:10
  • 3
    If your goal is to prevent having two versions created on the same day, this would do it.
    – JeffO
    Commented Jan 19, 2012 at 13:49
  • 3
    @JeffO Adding HHmmSS could also allow multiple releases per day.
    – StuperUser
    Commented Jan 19, 2012 at 17:24
  • 5
    Often several major versions are maintained in parallel, basically because new features tend to bring new bugs. Is 2012.01 better than 2011.11, or is it just a security patch variant of your long-term-support 2003.06 line?
    – user8709
    Commented Jan 20, 2012 at 1:45

15 Answers 15


This is something that you are going to have to take a look at from a couple of different angles as you need to take into account user needs as well as the needs of the software and developers.

In general, your customers aren't going to care very much about what the version number of the software is going to be as long as they know they are running something newer (i.e. Product 2012 is newer than Product 2010) and that they know it is up to date if there are patches that can be deployed (i.e. Product 2012, Update 10). As such, from a customer branding stand point I tend to prefer either a named releases (e.g. Windows XP, Windows Vista) followed by a strict sequence number of patches that may be installed by users.

That said though, writing software that checks things that are easy for the user tends to make the code under the hood much harder to write. Thus I tend to prefer the simple Major.Minor version scheme if only because you can do a simple number comparison to check to see something is up to date as in the following:

// Check to see if we can handle the file version
if (this.Version < fileVersion) {
   throw new UnsupportedFileException("The file version is " + fileVersion.toString() + " which is not supported");
// Do stuff ...

To put this in a bit of context though, I generally don't care how big the minor number gets (i.e. 1.1024) which allows the above system to keep running successfully. Generally the revision numbers are only of interest to internal development and I actually haven't even really seen them affect things that much beyond just giving things an additional number to keep track of.

However, the above two schemes really only don't apply to environments where continuous deployment is being used (i.e. Stack Exchange) which is where I tend to prefer some sort of date followed by a revision number as appears to be used on the Stack Exchange sites. The reasoning for this being that versions are going to change too often in the continuous deployment environment and you may have multiple versions of the code going up in the same day which justifies the revision number and the current date is as good as any for breaking things out even more. In theory you could just use the revision number for everything but use of the current date allows you to keep track of major milestones internally that could make things a touch easier to discuss.

  • 3
    We also have continuous deployment, and we use a major version + the date. It's simply the easiest way to keep track of what's going on. Quite frankly it's easier to query version control to pull out the source files for a given date than it is to constantly have to tag files and query that way.
    – NotMe
    Commented Jan 4, 2014 at 1:37
  • You shared code that does a direct numerical comparison of versions as if versions were numbers. I just want to point out the caveats that this would only work if you start with all the significant digits you would ever need (e.g. 1.0001) or if the minor version never goes above 9. In your example, (numerically,) 1.1024 < 1.1. (Usually versions are not considered numbers, as they are allowed to have more than one period character, and are not compared numerically.)
    – cowlinator
    Commented Jan 27, 2022 at 1:18

The problem with using a date, is that specifications are written against the counting numbers rather than a date when it's due.

"This piece of functionality is due to be in release 1. The other piece of functionality is due to be in release 2."

You can't refer to a date in specs, since the release date could get missed.

If you don't have such a formal process that needs different releases identified in advance, using dates is fine; you don't need to add another number into the mix.

Version numbers are unlikely to contain dates, since their context is linked to specs.
Build numbers are likely to contain dates, since their context is linked to when the build took place.

  • 8
    I'd argue that features often get pushed from one release to another and therefore any documentation given to a customer that "feature x will be in release 2" is likewise doomed to failure.
    – NotMe
    Commented Jan 4, 2014 at 1:38
  • @ChrisLively Absolutely. Speculative documentation and a language like "will be" rather than "expected to be" can be very painful. A good product owner will set the right expectations and plan realistically.
    – StuperUser
    Commented Jan 6, 2014 at 10:33
  • 3
    @NotMe Right. A specification that plans versions and release numbers further than a handful of weeks ahead of time is basically doomed to be wrong, unless you're willing to delay release until the features you wanted are complete. But the current trend is to release frequently, preferably on a regular schedule, which means you have little idea what features are going to be present in which releases.
    – Jules
    Commented Jul 23, 2016 at 9:01

Although this approach has benefits as you described, there are certain drawbacks if you use date as a version number:

  • Date based versions are flat. With v2.1.3 you can see the version number, sub-version number and sub-sub-version number. With 20110119 you can only see when it was written. You could group your date-based versions by month, but it still wouldn't tell you anything. You could have several slow months of small bug fixing and then two weeks of heavy coding resulting in a major release. Dates don't tell you that, regular version numbers do.

  • If you really really need to change the version on a daily basis and possibly release number it can indicate that you don't have a proper release process, but instead everyone wildly changes stuff and promotes it to production servers whenever they want. If so, you have a problem with the process, and using different version number schema isn't going to solve it.

  • 4
    Having multiple releases a day doesn't equate to having a release problem. What it might indicate is that you have a large project, where several people/groups are constantly working to release updates. These might be fixes or simply enhancements.
    – NotMe
    Commented Jan 4, 2014 at 1:41
  • Also, date based versions are no more "flat" than "2.1.3". Neither have meaning without context. For most VCS's pulling out a set of files by date is generally more reliable than pulling out by a label. For the simple reason that people sometimes forget to stamp a particular set of files with a version label while the VCS never forgets to date/time stamp the update.
    – NotMe
    Commented Jan 4, 2014 at 1:44

Versions are often used to convey information about how different a particular version of the software is from the previous one. So for example, if you upgrade from 1.0 to 2.0 of Acme, that's a major upgrade, in theory carrying major changes.

An upgrade from 1.0 to 1.1, on the other hand, is a minor upgrade and in theory carries minor, incremental changes and bug fixes.

This would be difficult to represent in a date format, though you could use a mixture. For example, v1.0.YYYY.MMDD

  • 2
    Just look at how Mozilla has changed its handling of version numbers recently. Major version numbers used to hang around forever, now it seems there's a new major version every few months. Why? - when they didn't bump the major version number, lot's of people didn't really believe there were any new features.
    – user8709
    Commented Jan 20, 2012 at 1:57
  • Yeah Chrome have a bizarre versioning scheme as well - I think they'll hit issues in a year or two when they're releasing version 21474836478.0. (Ok, I exaggerate slightly but they'll hit the stupid-number point eventually).
    – JohnL
    Commented Jan 20, 2012 at 9:34
  • 3
    @JohnL: I don't believe that the average Chrome user cares what major version it is in. The application automatically updates itself and "seems" stay the same even though a lot of changes have been made.
    – Spoike
    Commented Jan 20, 2012 at 10:35
  • @Spoike: True. I care mainly because I use the Secunia PSI, which checks whether you have the latest versions of things. It's always telling me that Chrome 15.x is end-of-life or some such thing
    – JohnL
    Commented Jan 20, 2012 at 11:03
  • Of course, the version numbers for the RSS standard are just mental.
    – JohnL
    Commented Jan 20, 2012 at 12:04

Without repeating good ideas from other answers, I have a problem in mind which wasn't addressed yet.

If you happen to do a fork, between an older version for backward compatibility, and a new version for an incompatible modernisation, you can't distinguish them via version numbers.

For example the Linux kernel was forked around the year 2000 into the old 2.4.x branch, which is probably still supported today and counts as 2.4.199, while the new version has been 2.6 for many, many years, and is 2.6.32 for older systems, but 3.2 for the newest kernels.

If you have documentation about your releases, you will double the information and tell the people, that version 20120109 arrived in 2012 at 01/09. Mh. But what, if there is a last-moment bug detection, and a release is delayed for a week, but the documentation, where the name is mentioned, is already ready, maybe printed, press information is out and so on. Now you have a discrepancy which is problematic, if version 20120109 arrived at 2012/01/13.

In SQL, the question whether IDs should carry semantic information has often been discussed, and the result is always: avoid it like hell! You're creating an unnecessary dependency. It can't be of benefit.

Ubuntu with its 04/10 scheme had its problem in 2006, when version 6.04 was delayed and became 6.06 . In year 3000 there will soon be the next problem! :)


There are many software packages that do indeed use the date as a version. Ubuntu comes to mind, where their version is YY.MM. And the build numbers for Microsoft Office products are also an encoding of the build date. Jeff Atwood wrote an Coding Horror blog post about version numbering, including this recommendation:

Whenever possible, use simple dates instead of version numbers, particularly in the public names of products. And if you absolutely, positively must use version numbers internally, make them dates anyway: be sure to encode the date of the build somewhere in your version number.

In my opinion, it doesn't matter as long as you are consistant and are able to go from a build version number (whatever it is) and recall all artifacts that went into that build from your version control system. Users don't typically care about version information at all, but rather the functionality provided by the system. Versioning information is only of real value to the developers.


Use semantic versioning - that way, you get some idea of the sort of changes being made between versions without having to inspect the code itself: http://semver.org/


Problem with using Dates as Version Numbers

The answers here are good, but I didn't see anyone address this concern with using dates: The user cannot determine how often modifications have been made.

What I am trying to say is that I can tell that Windows 3.1 and Windows 7 are far apart... and perhaps are incompatible. Windows 95 and Windows 2000 tells me nothing more than the year in which the product was introduced.

For example, with Python, I know that version 2.7.2 has evolved from 2.4.6. If I look further, I see that version 2.4.6 was released on December 19, 2008; and that version 2.7.2 was released on June 11, 2011. From this, I can form an opinion about the stability (i.e., frequency of release) of a product.

If, instead, Python had used release dates, I cannot know how these products might be connected. Further confusion would result, because Python 3.1.4 was also released on June 11, 2011 (the same as Python 2.7.2).

In short, I don't think that, by itself, date-versioning is valuable.


Using Version numbers is a way to show how BIG the change is

For example 2.4.3 may mean version 2 is the major change to the entire system. .4 is a minor update. and the last .3 is a small bug fix to that version. That way its easily recognisable how much has changed between each version.

Having said that I still see many people use dates or SCM revision numbers as version numbers so long as you have some way to track back to supporting release notes and documentation of what was in-scope for that release there is no real problem.


Some good answers here already, but I would like to point out a case where using dates makes perfect sense: small libraries or snippets of code where the code is likely to be updated frequently but in tiny bits with no single version differing drammatically to the previous one.

In other words I'm talking about situations where there's no actual "version number" but basically a sort of quasi-daily repository dump.

When I come across this kind of stuff I usually welcome the choice as it's more useful for me to know that I'm using a relatively current script/lib rather than a specific version.


Dates as a version number is good for marketing. If people are using "Windows NT 5.0", they might not realize it's obsolete. But if people are still using "Windows 2000", they'll instantly know it's a 12-year-old OS and be encouraged to upgrade.

However, it does make it harder to distinguish between "major" and "minor" updates.

  • 1
    And marketing helps you sell ;)
    – c69
    Commented Jan 20, 2012 at 0:00
  • Why should users need or "be encouraged" to upgrade, if the software fits their needs (including providing an appropriate level of security)?
    – user
    Commented Jan 20, 2012 at 8:51
  • 3
    Because support is dropped for it, and you stop getting security updates.
    – JohnL
    Commented Jan 20, 2012 at 9:35

Let's say some customers use version two of your product, and some have upgraded to version three, and that upgrade is not a decision made lightly.

Say the last version of version two is 2.3.2, and version three is at 3.0.3. Now you find a vulnerability that absolutely needs to be fixed, so you release 2.3.3 and 3.0.4 on the same day. Can you see how the release date is totally irrelevant? You may have stopped work on version two in 2013 and only released some essential bug fixes since then. The date is irrelevant compared to the version number.


I don't like this idea, for reasons already described by others. Just use the major.minor.bugfix scheme - there's a reason why most people do it this way.

But whatever you do: pick one version-naming scheme, and stick to it. Don't do it like Windows, where they change the scheme with every release. And don't do it like Android, where each release has an API version number (8), a version number that's intended for marketing (2.2) and a stupid name (Froyo).


Date As a Version

If your product is not sold then just using the date is fine and probably useful. If you sell it and upgrades to customers they want to buy a model with a specific set of features. It is much easier to sell them on an upgrade if this model has a clear name, it does not really matter what it is but for example no one really buys the 2012 Jan 20th Ford Car they want the Kia Model whatever. The same is true of software. Giving a hard model name and version means it has features different from an older one. For me just a date does not do that, it says I made it then, not it might have new features.

Scheme We Use

I made no claim that our system, creates a clear brand as above. We now use a four part scheme. A version number, state, the date and a checksum.


This may seam over the top but it allows for us to have several versions of the build for version 1200 that our engineers can use and we differentiate between them by date. The state tell people if it is a internal test version, customer patch build or gold release. The checksum is new, it allows an engineer or customer to verify that they actually have downloaded the correct one from our distribution.

So we might have a sequence of


We only normally refer to the major version numbers to customer ie "12" but a customer will get the latest gold version of 12 ie 1200_GLD_120120_F0D1 unless they need the Fix.


Many answers here.

I want to address a problem that was not addressed yet: ambiguity.

A version and a code state (a.k.a "commit" or "revision") should have a 1-to-1 mapping, meaning that each version should have a unique code state.

With just a date (that has single-day resolution), you can't do that. If you build, make changes, and build again in a single day, you have 2 different builds representing 2 different code states, but they share the same version.

If a user experiences a bug, and sends you the version, you still don't know what state the code was in for that build.

Even if you increase the date resolution to the second, all it does is make a version collision less likely, but it doesn't technically eliminate the possibility, because 2 people on 2 computers could technically complete their builds in the same second.

  • I worked at a place that added a build number, which was increased every time a new version was built by the build machine (and everything released came from the build machine). Still the "normal" version number was also there, but it allowed having different development versions.
    – gnasher729
    Commented Aug 8, 2022 at 11:49

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