How does a software engineer version two minor updates at the same time?

Question

In a web app I am building, I might finish two distinct minor features at the same time: Implementation of a new web page, and implementation of the notification bar. After merging both of these into master on GitHub, and resolving any existing conflicts, I will release it.

My current release is v0.9.1

When I release again, there will be two new minor changes. Would it become 0.11.0, 0.10.0? The https://semver.org does not seem to give any insight on this scenario.

Note: I would ask this on webapps SE but semantic versioning does not have its own tag. It seemed more likely to get an answer on this site.

Answer 1

TL;DR:

• For a release with new features that don't change behaviour of any existing features, increment the minor (Y in x.Y.z) version by one.
• For breaking changes (especially where an automated workflow or API consumer would be affected) semantic versioning states you must increment the major (X) version.
• When you do releases, always increment the version numbers by one, regardless of how many fixes/features go into the release

---

Semantic Versioning is really about APIs and backwards compatibility:

1. Software using Semantic Versioning MUST declare a public API.

If you are trying to follow it for general purpose software (eg, not necessarily an API) you have to take a bit of a looser interpretation. All it says on incrementing for new features is:

7. Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API.

   It MAY be incremented if substantial new functionality or improvements are introduced within the private code.

8. Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API.

So basically if you're not changing any existing functionality (breaking backwards compatibility) then it's appropriate to increment the minor version.

Increment

It also only talks about "increment" and doesn't specify count, but every project I've ever come across increments by one, regardless of how much goes in. If you were to try to increment by the number of features you introduce in a single release, you cause two pointless problems: (1) debate about how to count "features", and (2) you end up with versions that look like 1.55.0, 1.92.0, 1.101.0, etc.

What's a 'release'?

As far as how many features go into a release, that's more art than science. There's usually a few factors involved, including:

• If the new features are related or dependent on each other
• How much time has passed since the last release
• How much longer will it take to finish the remaining features
• If there is someone or something waiting for a specific feature (another product, specific user(s), etc)
• If you want a release to generate publicity/interest/etc
• How much work/pain it is for you to do a release, and your users to upgrade (high effort upgrades + many release = unhappy users)

Major Versions

For general software, there's also often an artificial increment of the major version, even if the release is not backwards-incompatible -- releasing 2.0 simply makes a bigger "splash" than releasing 1.19.0. This is really just a judgement call, and unless there really is a major backwards-incompatible change, it has more to do with marketing than anything technical.

If you have a release that introduces significant new features but maintains backwards compatibility and you increment the major version anyway, you'll get basically no complaints (at least none worth listening to) about not strictly following semantic versioning.