Odd versioning systems
Written , a 3 minute read
Recently, I started to have personal project that are used by not only me (!) so I had to choose and commit to using some kind of versioning scheme. The obvious choice, semantic versioning was picked by this task lead me to looking into the history of versioning schemes. I would like to highlight some of the weirder ones.
Knuth Versioning (1982)
The original weird versioning system comes from one of the legends, Donald Knuth. What you would do when you develop one of the foundational systems and strongly belive that future compatibility is more important then new features? Introducing versioning of TeX typesetting system, which from version 3 froze time and only allow bugfixes. Since we reached the design goal, now we only sort out how well we approach it - similar to how by creating new approximations we are closer to π.
That's why TeX utilizes approximations of π as version numbers, with the π itself beeing set as version number when we made the final change.
I love this approach and with that more projects would adopt this more artistic way of expressing the final version and our approach to it. The only issue that I would see is worse accesibility - comparing long string of π approximations digits is way harder then other versioning schemes.
One interesting effect of frozen projects is how the improvements are developed. TeX instead of beeing one monolith that defines how to do things right with few weird semi-compatible unofficial implementions, is a root of rich ecosystem that allows users to choose their preferences or develop their own solutions. Forks don't need to always chase the main project and can focus on their developement.
Negative numbers (1995)
Short side note from coherent narrative of freezable versioning systems. How would you define that the version is not ready for public use? Projects like Zig have this problem, where despite the calls to not use it in production and versioning scheme suggesting that nothing is stable and ready, it is already used in major projects, like new JavaScript runtime Bun.
SmartEiffel provides the answer, with version numbers beeing initiality negative, to emphesise the development stage of the implementation.
You can find source code of SmartEiffel here.
Kelvin Versioning (2010)
Kelvin Versioning is a bold move to create software that lasts small and well defined. It is more of an artistic approach, aiming to help find the true golden gem for given software by limiting how much we can bloat.
It SHOULD NOT be used for non-artistic purposes, since it by design prevents security updates.
How does it work? Releases are described by single integer, denoting the temperature of the system. Temperature can only drop down and stops at absolute zero. Temperature of a component must be warmer then all of it's dependencies or they both need to be at absolute zero. When temperature of dependencies declines, the component temperature must also decline.
I must say, I'm really excited to use Kelvin Versioning sometime. All of my projects are in the state of might pick up sometime and defining one to have clear limit is exciting. Exploring the recursive nature of dependencies versioning is however, a little bit tricky to implement - I would need to develop whole ecosystem for that. One project in the backlog that comes to mind is defining Turing Machine programming language (idea from Tsoding's Tula), and defining simple stack based forth-like language for it.
Comparison beteween Knuth Versioning and Kelvin is interesting: Knuth provides a method to push security updates, but lack the completness of Kelvin, with recursion definition of dependencies version requirements.
Find more: