GitLab Pipelines for automated publishing of a semantic version

[suchona.kani.z]

Versioning software is a practical way to record the current development status. However, software versions are often only incremented and do not add any value. Since versioning can be mapped into rules, this process should be automated. Semantic versioning gives software versions a structure that can provide important information to all stakeholders and the development team.

To follow this blog post, you should have basic knowledge of GitLab CI/CD and Docker .

The Hell of Dependence
Versioning software is not a revolutionary idea. Suppose software package A has been further developed. Versioning of software package A is done by increasing a sequential number.

Software package A is released with a new version and software uk consumer email list package B blindly updates its dependency on software package A. In doing so, the software in package B may no longer work as expected. The new version of software package A contains changes that have fundamentally restructured the API.

With the help of a semantic version, it would have been noticed during the development of software package B that the new version of software package A contains important changes.

Semantic versioning
A semantic version is formed based on MAJOR.MINOR.PATCH. The individual elements are increased as follows:

1. MAJOR is increased when the API has changed fundamentally.
2. MINOR is increased when new functionalities have been added.
3. PATCH is increased if changes only fix bugs in existing functionality.
This structure allows us to inform users about the nature and extent of changes. When we update software dependencies in one of our projects, we still need to be responsible and verify that the software packages work as described.

We can automate the detection of a new version of a software package in a CI pipeline. To automate this process, we need a foundation and a set of rules to determine what has changed since the last version of our software.

Git commits and commit conventions
To record what changes have been made to the software, you use Git's commit messages. There are many structures for structuring Git's commit messages, I like to follow the Angular Commit Conventions for this . The Angular Commit Conventions define strict rules to make the commit messages more readable.

Angular Commit Message Convention
The structure of the message is simple.