I’ve talked a lot recently with colleagues and peers about writing git commit messages (particularly in the wake of Hacktoberfest, but also following this recent post: One to read: “My favourite Git commit”), but this is a useful document that lists the standards to follow, no matter where your commits are going!
I try to follow these guides (heading no more than 50 characters, body containing the changes that occurred and why) but I don’t always succeed. But, it’s a goal to aim for!
SemVer, short for Semantic Versioning is an easy way of numbering your software versions. They follow the model Major.Minor.Patch, like this 0.9.1 and has a very opinionated view on what is considered a Major “version bump” and what isn’t.
Sometimes, when writing a library, it’s easy to forget what version you’re on. Perhaps you have a feature change you’re working on, but also bug fixes to two or three previous versions you need to keep an eye on? How about an easy way of figuring out what that next bump should be?
In a recent conversation on the McrTech slack, Steven  mentioned he had a simple bash script for incrementing his SemVer numbers, and posted it over. Naturally, I tweaked it to work more easily for my usecases so, this is *mostly* Steven’s code, but with a bit of a wrapper before and after by me :)
So how do you use this? Dead simple, use nextver in a tree that has an existing git tag SemVer to get the next patch number. If you want to bump it to the next minor or major version, try nextver minor or nextver major. If you don’t have a git tag, and don’t specify a SemVer number, then it’ll just assume you’re starting from fresh, and return 0.0.1 :)
Want to find more cool stuff from the original author of this work? Below there is a video by the author :)