Fork me on GitHub

Why 2.0.<commits>?


@jshaffer2112 All my projects follow MAJOR.MINOR.COMMITS these days -- same as many of the Clojure tools. I think it's a better model than SemVer.


Per the HoneySQL README: > Once the prerelease testing is complete, this project will follow the version scheme MAJOR.MINOR.COMMITS where MAJOR and MINOR provide some relative indication of the size of the change, but do not follow semantic versioning. In general, all changes endeavor to be non-breaking (by moving to new names rather than by breaking existing names). COMMITS is an ever-increasing counter of commits since the beginning of this repository.


Why the commits counter though, as opposed to incrementing by one? It seems like a very considered choice, but I haven't found any explanation of the reasoning behind it


The commit counter is easy to base a version on programmatically -- has a built-in function for that -- and it gives a sense of how much change has occurred between two releases. It also makes it clear you're not using SemVer (which just incrementing the patch slot would look like).


The Clojure CLI, tools.deps.alpha, and several other libraries have all adopted this so I think it's a good model to follow.


@jshaffer2112 Alex told me "commits is a meaningful, monotonically-increasing, quantitative description of version over time. major.minor is a subjective, human oriented description of version. Combined, you get both."


(and I agree 🙂 )


Thanks! That makes sense