Note: This site is currently "Under construction". I'm migrating to a new version of my site building software. Lots of things are in a state of disrepair as a result (for example, footnote links aren't working). It's all part of the process of building in public. Most things should still be readable though.

Date Based Versioning - An alternative to Semantic Versioning

TODO:

- Update the meta description - Make sure the regex you have works. - Create a few more examples. - Reference to http://semver.org - Go through the FAQ on http://semver.org and answer the same set of questions.

Version numbering

Version numbering in software is a pain in the ass. There are some good guidelines but even with them, I spend way to much time trying to figure out if the changes I'm making mean I should move from:

1.3.3 to: 1.3.4 or: 1.4.0 or: 2.0.0

That's the semantic versioning.

What I'm thinking of now is much higher level.

1--2015-01-07-1 1--2015-01-07-2 1--2015-01-07-3 3--2015-11-31-21

The format is:

- An integer - Two dashes - The current date in ISO 8601 format - One dash - An integer

Other notes:

- Both the first and last integers can be one or more digits. - Neith has leading zeros. - The first integer can be a zero (but can't be negative). - The last integer cannot be zero.

The regular expression to match this is:

\d+--\d\d\d\d-\d\d-\d\d-[1..9]\d*

The two dashes between the initial integer and the date make it easy to parse visually. The reason there is only one dash between the date and the last number is because it's easy enough to pick it out since it's at the boundry. The date is very easy to pick out for versions "-1" through "-9" because each component has multiple digits thanks to the leading zeros in ISO 8601. Even when version "-10" is hit, it's still relatively quick to pick out the date component because it's all the digits after the double dash that's not the last number.

This eleminates a ton of mental overhead when trying to work out a version number. The only time a decision needs to be made is when to increment the major version number. In most projects that's pretty rare and very obvious.

Naming of branches is left as an exercise for the reader.

What about all the MAJOR MINOR PATCH information that's provided in semantic versioning. As a consumer of software, the only number I can are about is the first one which warns me if the software might break compatability in an update. The same info is available in the date based versioning. As for the minor v patch info, as a consumer, I dont care. I'm going to read the release notes and make my decision to update based on that. (I've got so much software running that I don't remember the explity current versions anyway without looking.) As a producer of software this just adds mental overhead. Whether or not the change I just made falls into the Patch category or a new feature is largely irrelevant. It's something I want the software to do.

Also, for projects the release often it's weird when the second number hits double digits.

1.17.2

So, bascially I don't need that info. As a consumer, the only thing I reall care about is if it's a major version update or not and, again that info is provdied by the first number in the date baset version system.

Another nice thing about this is it's easy to automate. Everything other than the first major version number is date based or iteration based. Except for incrementing the major version, there's no requiremnet to make a manual decision about how to update the version number.

If you have less than ten versions a day, computers will automatically sort the strings properly.

Way fewer rules to deal with than semantic versioning.