http://legacy.python.org/dev/peps/pep-0440/
We can mostly say that version numbering thanks to "Windows 9" has shed an interesting spotlight on version comparaison.
They are to tenants of version handling:
- the naïves who consider versions has strings;
- the picky people who consider version has a very dark grammar that requires to be parsed with an ABNF compliant parser.
Well, of course, I don't agree with anyone :) Versions are just growing monotonic numbers written in a weird base but they must have at least comparaison operator: equal, superior/inferior, is_in.
Naïves people are wrong of course
It gives the famous reasoning why windows might jump to windows 10:
https://github.com/goozbach/ansible-playbook-bestpractice/blob/915fce52aa82034cfd61cfbfefad9cf40b1e4f48/global_vars.yml
In this ansible playbook they might have a bug when centOS 50 will come out.
So, this does not seems to hit only the «clueless» proprietary coders :)
Picky peoples are much to right for my brain
Yes, python devs are right we need a grammar, but we don't all do python.
Given Perl, freebsd, windows ... our softwares need versions not only for interaction with modules/libraries within the natural ecosystem (for instance pip) but it should also nicely fit in upper container version conventions (OS, containers, other languages convention when you bind on foreign language libraries ...). Version numbering needs a standard. And semantic versionning propose a grammar but no parsers. So here I am to help the world.
The problem is we cannot remember one grammar per language/OS/ecosystem, espcially if they are conflicting.
PEP 440 with the post/pre weird special case does not look like very inspired by the tao of python (at my wrongful opinion of someone who did not took the time to read all the distutils mailing list because he was too busy fighting against a lot of software bugs at his job, and doing nothing at home).
So as when there are already a lot of standards you don't understand or cant choose from ... I made mine \o/
Back to basics: versions are monotonic growing numbers that don't support + - / * just comparisons.
Version is a monotonic growing number.
Basically if I publish a new version it should always be seen superior to the previous one. Which is basically a number property.
In fact version can almost be seen as a 3 (or n) digit number in a special numbering such as
version_number = sum(map(project_number_in_finite_base(("X.Y.Z").split(".")))
The problem is if we reason in fixed numbered based logic, we have an intel memory addressing problem since every X, Y, Z number can cover an infinite range of values they can be a loss of monotonic growth (there can be confusion in ordering).
So we can abstract version number as digit in infinite bases that are directly comparable
I am luckily using a subset of PEP440 for my numbering that is the following http://vectordict.readthedocs.org/en/latest/roadmap.html
By defining
X = API > Y = improvment > Z = bugfix
I state for a user that: given a choice of my software I guarantee your versions number to be growing monotonically on X / Y / Z axis in fashion such has you can focus on API compatibility, implementation (if API stay the same but code change without bug, it is a change of implementation), correctness.
As some devs, I also use informally "2a" like in 1.1.2a to notice a short term bugfix that does not satisfy me (I thus strongly encourage people to switch from 1.1.2x to 1.1.3 as soon as it comes. I normally keep the «letter thing» in the last number
If people are fine with API 1 implementation 1 they should be easily able to pinpoint versions to grow to the next release without pain.
So how do we compare numbers in a n infinite dimensional basis in python ?
Well, we have tuples \o/
Thanks to the comparison arithmetic of tuple they can be considered to be a number when it comes to "==" , ">" and these are the 2 needed only basic operations we should need to do on versions (all other operation can be derived from the latter).
Version is a monotonically growing number, but it is on a non fixed base.
Next_version != last_version + 1
if version is a number V comparaison of V1 and V2 has sense, addition or substraction cannot have.
One of the caveat though of version numbering is our confusing jargon:
if we decided version where X.Y.Z why do we expect version 2 is equivalent to 2.0.0 instead of 0.0.2? Because when we say python version 2 we expect people to hear python version 2.x and preferably the latest. Same for linux 2 (covering 2.x.y ...) it is like writing the number «20» «2» and expecting people to correct according to the context.
So the exercise of version comparaison is having a convention to know how to compare numbers according to API, implementation and bugfix dimensions hierarchically speaking in respect to the undetermination introduced by human inconsistent notation.
Just for fun, I made a parser of my own version string to a numbering convention including the later twist where 2 means 2.0 or 2.0.0 when compared to 1.0 or 1.0.0. It addresses the examples to solve given in PEP440
It can be seen here.
Wrapping up
For me a version is an abstract representation of a number in infinite base which figures are hierarchically separated by points that you can read from left to right.
I am saying the figures are made of a tuple of two dimensional space of digit and letters where digit matters more than letters. (Yes, I am putting a number in a figure, it is sooo fractal).
But most important of all, I think versioning string is a representation of a monotonic growing number.
I am pretty sure PEP 440 is way better than my definition is has been crafted by a consensus of people I deeply respect.
My problem, is that I need to achieve the same goal as them, with less energy they have on modeling what a version number is.
That is the reason why I crafted my own deterministic version numbering that I believe to be a subset of PEP 440.
Conclusion
My semantic might be wrong, but at least I have a KISS versioning system that works as announced and is easily portable and for wich I have a simple grammar that does quite a few tricks and an intuitive comprehension.
And human beings are wrong too (why version 2 is 2.0.0 if compared to 2.1.1 and 2 if compared to 2.1 or 2 if compared to 3), but who cares? I can simply cope with.
NB it works with "YYYY.MM.AA.number" (SOA) scheme too,
PS thinking of adding y-rcx stuff by slightly enhancing the definition of a figure.
PPS I don't like talking to people normally so I disabled comments, but for this one I am making an effort : http://www.reddit.com/r/programming/comments/2iejnz/an_opinionated_versioning_scheme_based_on_mapping/
because I am quite curious of your opinions
