Through a bit of coincidence a friend and I were having a discussion on version control and how we went about naming our versions a few days ago, and I say coincidence, because it seems like we’ll also be working on Semantic Versioning sometime along the line in class.
Being the person that I am, I made my own rules without being influenced by anyone else. For me, I simply though that
Well… It’s my code, right? That means I can name things however I want, right? So if I said this is version 0.9, then it’s version 0.9! Or if this is version 2.0, then it’s 2.0!
In response, my friend informed me of a few soft rules, since he was more familiar with versioning through an internship opportunity than I was, and he shed some light on a few details. Like how versioning is not just a made up number that you assign to your project/code. Hearing this, I was honestly pretty confused, but I looked into it and discovered Semantic Versioning!
And wow, did that blow me away. Looking back at the way I approached things, I was no different from a headless chicken running around! Learning about Semantic Versioning, through this video, it is both so straightforward but also so useful. No longer will I have my versions be numbered willy-nilly, nor will I even forget my own versions and what happened in this update! It’ll finally make sense!
To break down Semantic Versioning, consider versions as three parts!
The Major version, so think 1.0.0
The Minor version, such as 0.1.0
And finally, patches, like so 0.0.1
Major versions are, well, major! These are versions that leap forward and have large changes! Making a major version usually implies that the code is changed in such a way that it will no longer work with older versions. These changes might be large architectural changes, or other large scale changes that usually break the existing structures or APIs.
Minor versions are NOT as massive (duh), but they come with plenty of other things compared to, say, patches! Minor versions could be added features, or updates to existing features, and most of the time, nothing should break. Functionality that existing before should still work, and further development of new features shouldn’t impact or break anything either (ideally).
Patches are like bandages! These are where the bug fixes are! If something is broken in an unintended way, that’s when patches come in, and they should be used to iron out problems that were not accounted for. It could be something minor like the output of some code is a 2 instead of a 1, or it could be a bit more major like a whole portion of the code crashes when run, but patches are for fixes!
As an example, I’ll run through a brief bit of versioning on a made up project! Let’s say… I’m making a program to print out a leaderboard. It connects to an online library to gather scores, and then displays it to whoever connects to it.
After long and grueling work, I did it! I finally completed it and so, I release…
It’s done and completed, but then… It turns out, my leaderboard only prints out the WORST scores! Dang it, I flipped the list around by mistake! So off I go, fixing this bug. After everything is working again, my next version should be 1.0.1.
But then… I think to myself, wouldn’t it be cool if I added region support too? Then we could see where this score is from, and potentially even group regions by high scores!
So, after adding this new feature, my next version will be 1.1.0!
Pretty straightforward, right? It’s really clear what is going on too!
Let’s say another bug is introduce, bam, 1.1.1!
Then more features, 1.2.0
And finally another bug is squashed! 1.2.1
And… another bug ! 1.2.2
But… then wait, there’s another bug. 1.2.3
Things feel good and everything works, but I learn about a whole new library that does what I want it to do, and gives me more room for growth. So rework the whole program with this new library! The old stuff still works, but since I’m switching to a whole new system, this version will no longer work with the old one, and now, this is when I jump a major version.
We’re now on version 2.0.0!
I hope that example made sense! There is more to semantic versioning as well, but that is the quick break down. Introducing things like alpha/beta and also ^ and ~ adds some other intricacies, but for now… Let’s not think about them! Alphas/betas are optional for testing purposes, and to be honest, ^ and ~ are a bit out of my grasp. I don’t fully understand them yet! I’ll look into them more, and maybe I’ll have a future update post detailing what I’ve discovered!
From the blog CS@Worcester – Bored Coding by iisbor and used with permission of the author. All other rights reserved by the author.