Automating your versioning (part 1)

Hey everyone.

As promised, I am writing this new series on how to automate your releases/versioning using a git based source code control management. To achieve this I believe I might write two or three blog posts, let’s see how it goes.

I started from the end showing a release automation process, but there are few steps before that you want to learn.

EDIT: Below I am posting the links for the complete series, if you want read it all:

• Automate Your Versioning (Part 1)
• Automate Your Versioning (Part 2)
• Automate Your Versioning (Part 3)
• Release Automation with Gitlab CI
• Deploy with Gitlab CI

SPOILER ALERT: it is all about standardization.

Semantic Versioning

That is the first thing you would want to learn if you want to progress in the software engineering field. It is not the only way of managing your software versions, but it is one of the most used.

I could spend some time speaking of it, but I will boil down to a couple of paragraphs.

The version should look like X.Y.Z = MAJOR.MINOR.PATCH. In summary, (from semver.org):

1. MAJOR version when you make incompatible API changes,

2. MINOR version when you add functionality in a backwards compatible manner, and

3. PATCH version when you make backwards compatible bug fixes. Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

In LabVIEW the major version would be something as modifying the connector pane of the VI or modifying a class or cluster in a way, that would break the code that are using it (broken VI arrow).

So, if you want to dig a little bit more about it, the semver.org website details all possible cases, including builds, beta, alpha, pre releases. It has also some predefined Regex expressions for validation of the versioning.

A caveat though: the use of v before version is not standardized in semver. It states that this is a tag version, and not a semantic version. But, as you will see, it is widely used across all projects using git.

Is “v1.2.3” a semantic version?

No, “v1.2.3” is not a semantic version. However, prefixing a semantic version with a “v” is a common way (in English) to indicate it is a version number. Abbreviating “version” as “v” is often seen with version control. Example: git tag v1.2.3 -m “Release version 1.2.3”, in which case “v1.2.3” is a tag name and the semantic version is “1.2.3”.

Conventional Commits

The second thing to learn it is the conventional commits. Haven’t you ever asked yourself if there was a standard for commit?

Let me answer you, yes, there is. It is called “conventional commits”.

All of the “standard” is described in their website , conventionalcommits.org, some uses cases, and some tools (which I will describe how to use one of them in a second post). It is also widely used in open source projects and I believe in non open-source too.

So, there isn’t a talk about how the commit should look like, if it looks like this or that, it is standardized, all you need is follow the guidelines. In my current journey, trying to adapt to this standard, I learned you will need some extra ingredients:

• Patience
• Discipline
• Don’t ever “git add .”

You will see that after a while, things will start flowing better, and this commit stage will be more automatic.

The hardest thing is definitely the “git add .” command, it is going to take a huge amount of time before you commit the first times. The commits will be more “surgical”, and the description of the changes will be more and more accurate.

An ultimate question: Why bother?

The main reason behind standardization is the use of community tools for automating process of generating changelogs, documentation, automatic versioning, and many other things that we can’t imagine. People are criative.

On the other side, your projects will look more predictable, and after a third one seeing one or two of your projects, he is probably going to understand how you did and where the things are.

It is so hard…

It is not all roses, but in the next posts I am going to show how to use tools to enforce this standardization, such as the use of the tools for conventional commits and to check if you are doing it the right way.

Until there…