I'm a big fan of really simple versioning schemes.
<rewrite number>.<release number>.<commit number>
Any version ending in a "0" is stable. IE:
- 1.0.0
- 0.1.0
.....
- 999.999.0
Whenever you are doing a "release" you have tested every feature fully to make sure the software is up to spec. Whenever you are doing a "rewrite" you can assume that the software's APIs have changed and you will need to readjust compatability (ideally APIs never break but this is one example).
With this you get the following:
- Is this stable to use in production.
- What software can work with what other software (looking at the major version it requires)
- Between which two commits a functionality broke. (If 1.1.157 works and 1.1.158 doesn't then you know commit 158 broke something)
With the author's versioning system:
- The month, year and # of commit you're on
- If someone else gave us this code (pr-)
- If there is active development on the code (dev-)
I prefer the former but I can see some of the benifits of the latter. I'm just more of a fan of using flat and simple numbers and not relying on "dev-", "pr-" and the infinite amount of tags that will follow if you start allowing them.
I don't see an advantage over SemVer- SemVer is an accepted standard while this is not and you still have the human error component arguably beeing the weak spot for SemVer. And to be honest: this is by no means simpler than SemVer.
I like `git describe --always --tags`. It gives me a string like "v0.4-10-gd7b8" assuming I have tagged my repo with semver like "v0.4". More precisely, that string means 10 commits on top of tag "v0.4" and you checkout revision gd7b8 to get it.
With this you get the following:
With the author's versioning system: I prefer the former but I can see some of the benifits of the latter. I'm just more of a fan of using flat and simple numbers and not relying on "dev-", "pr-" and the infinite amount of tags that will follow if you start allowing them.