💾 Archived View for gemlog.blue › users › sloum › 1627859067.gmi captured on 2024-08-18 at 20:51:56. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2021-11-30)

-=-=-=-=-=-=-

It is common to version software with a major, minor, and (potentially) patch version. For example: 1.23.2

I do not like doing this for my software and it always has felt arbitrary and based on when I bother to increment a number. I have been working on a scheme-like language (for fun and relaxation) and have decided to go another way. I use git for version control. So for my current project, which is called slope, the -v output looks like:

Version Number: 24
Build Hash: ca5e26238a8a48384740c04b3bc90ced0efed5ab

The version number is the commit number (as in, quantity of commits at the time of build). The build hash is the commit hash. This makes versioning real for the project. I provide a hash and you can always get the version you have a hash for on record. For big projects or commercial projects I guess I understand so-called semantic versioning... but otherwise I think providing a commit hash and calling it a day does the job. Really, I may drop the "version number" from my -v output and just have the hash, which is the actual actionable piece of information.

Anyway, just some random thoughts. This project i very very unlikely to ever end up in a software repository like apt or the like, so this seems to suit the situation well. :)