Implementing semver within a development pipeline when building libraries

Question

This is not about the specification of semver itself (which is crystal clear), but rather about the best approach to implement it within a development pipeline when building libraries.

---

TL;DR: who/what sets the version and deploys the artifacts, and when?

---

We're planning to opensource some of our internal Maven-based GitHub-hosted Java libs as they might be useful for others. What we currently have:

• CI pipeline via GitHub Actions, running the tests on PRs going to master, as well as master directly each time it's updated.

Now, what's the best approach to update the version and deliver the artifacts? I can see several:

• Being "release-driven": each time a GitHub Release is manually created via the GitHub UI (github.com/owner/repo/releases), another pipeline starts, reads and fetches the created tag, runs mvn versions:set then mvn deploy (put simply). The actual committed POM's version then doesn't need to change, e.g. can stay at 0-SNAPSHOT.

• Being "merge-driven": each time a PR is merged to master, roughly the same pipeline as above triggers, but uses the version of the POM (or auto increments the patch number by default, or something along those lines). A corresponding GitHub Release then needs to be created, either automatically or manually I guess.

• Being entirely manual: some dev needs to mvn deploy manually after having dealt with the versioning and the release somehow.

• Your approach.

How do people proceed out there? Is there one best approach? For our internal services and libs, a successful merge to master increments some version number and triggers a deployment, but is it the right approach if we want to follow semver strictly?

And because semver gives sense to versions, I guess it cannot be entirely automatic, can it? I believe some human must need to know and tell the system whether the coming release is a patch, a minor or a major one?

One case to keep in mind as well, is when a change (for instance a security patch) needs to be backported to an older version that is still maintained.

---

I originally asked this question on opensource.stackexchange.com, but I noticed it wasn't really related to OSS, but rather semver, so I'm trying my luck here instead.

Answer 1

When you are talking about an open source product, the versioning and release schedule is based on the policies of the team. When I was taking part in some Apache Software Foundation projects the process went something like this:

• Team decides on SemVer policy (i.e. what number is coming next)
• Officers determine when release cycle begins
• Project lead deploys those versions

NOTE: this was before the days of ubiquitous CI/CD pipelines and package managers. So a lot of the process is automated.

However, the variation I see now is that the project officers are in charge of what gets promoted to the release branch (whether that is master or a dedicated named branch is based on the policies of the team).

There are no hard and fast rules, but the big thing with open source is getting community consensus. That's usually garnered via Slack, Gitter, Mailing Lists, or some other form of asynchronous communication. When the team agrees on a direction and set of features, that drives what the next version number is.

Major changes in direction were usually developed on a branch that would some day overtake the main branch. That way the minor version updates and bug fix updates would be delivered from the main branch until the major changes were ready for primetime.