As with all great software, we build our products and releases in the spirit of continuous delivery. It is akin to creating a picture memory of where your product was at that point in time - the SDLC snapshot.
In the packaging of one of my projects, I came across a scenario that caught me off guard: versioning. Specifically, my challenge came with the choice of what versioning system I would use or how I would combine multiple versioning techniques if the need arose.
Working with multiple teams and in different demographics, packaging has always been different. For one, we have the SemVer evangelists, the CalVer antagonists(e.g Ubuntu packaging), the build version engineers and my just discovered git commit hashing brooders. Lo! How The choices go on.
I want to share with you the two that have piqued my interest so far and what options I use to curate experiences for the web.
A Case for Semantic Versioning
Semantic Versioning or simply SemVer, is a system of packaging software in which major, minor and bug fixes or enhancements are noted.
MAJOR**.MINOR.**FIXES
Examples:
Django 4.1.5
ColorDetect v1.6.0
fancy-git v7.1.9
Here, we would bump each version according to what purpose it serves. With this in mind, one of the major advantages that comes with SemVer is human readability. Engineers and users alike can clearly tell what came after the other. User A, will see that your product, ‘Legendary Lemons’ has a version, v3.0.0 while they have v1.2.0. Subsequently, they can tell that what is on your site is of a higher value if we were counting from 1 to 10. The same goes for your team members, albeit with a little more technicality.
Git commit Hashing strikes back
When it comes to using git commit hashing for software versioning, Fred Simon’s 7 Deadly sins of Versioning comes to mind.
Scenario
What if I needed to consider a component that had no impact on either functionality, performance or quality? Would I release v1.4.5 due to a spelling mistake in the README? Clearly, this is a developer-centred update in which a config file on the main branch needs to be updated for the project to run on the local environment. Should this be transferred to the user? What is the extent of items that should be? Ahh... the conundrum. Release management can be messy.
However, the challenge comes with interpretation. Surely 5517829933722 should mean something more than an array of digits. Is it higher than the others? Is it lower than the package I have?
Release management can be messy.
The pill
I packaged The Urbanlibrary as a docker container. We have dev-centered versioning and what is made known to the public. A mix and match if you may. Taking what works, modifying what I needed and sharing the much-needed value.
Example:
Consider the Windows operating system packaging. We have Windows 11, Windows 10 and so forth. In between these, we constantly have updates for the software. Patch upon patch each modifying the previous build.
I might as well merge these two schemas. Ultimately, what matters is that:
The product has clear documentation
I can see what happens across multiple builds
Automation sits at the center of deployment and changelogs happen on the fly as much as they can (I am not going to do an SSH every single time ).
Conclusion
What I have come to understand is that just because something is well-known, does not always mean it is the right way to do it. There is a plethora of choices on the table and I welcome thoughts and conversations on the same. I am keen to discover what your team or you personally use or would use to version your project. Reach out, touch base and let’s #build.
PS: For some anecdote, I stumbled on Julie’s video on how she chose to version her projects in general.
Image credits:
People illustrations by Storyset
Monkeyuser
