When should a commit not be version tagged?

Question

Context: I recently found out about Semantic Versioning, and am trying to determine how to best use it practically for my own projects.

Given that semver takes major changes, minor changes, and patches into account for versioning, when should a commit not be tagged with an updated version? It seems to me that every change would fit into one of these categories, and so every change should be versioned, but when I look at various popular projects on GitHub this doesn't seem to be the way things are done (just looking at the fact that large projects have tens of thousands of commits, with only hundreds of tags).

Answer 1

SemVer concerns versioning releases, not commits. If your version control model happens to require that every commit to master be a release, then yes, every commit will need to be tagged according to the degree of the change.

Generally, though, projects develop a mostly stable product on master and tag the releases they deem worthy of support. When they do so, they will tag according to their versioning scheme, which doesn't necessarily have to be SemVer in particular.

Answer 2

Version numbers are allocated to releases. In general not every commit should be a release. There are several reasons for this.

Firstly while you say you "test" every commit there are levels of testing. Running an automated testsuite on one machine is all well and good, but in complex software it probablly wont' catch every issue. Some issues may be hardware or configuration specific, some issues may be more about human-subjective considerations than about hard testable requirements.

Secondly bumping the major version number should be a rare action. It basically means that everything that depends on your software needs to be manually checked to see if it depends on any of the removed features.

A consequence of this is you should only add features to your "public API" in full (not alpha/beta) releases if you are prepared to support those features in their present form long-term.

Thirdly it's helpful to keep the number of versions in widespread use down. Even on a stable branch it is often better to gather a number of fixes together and make a single release than to make a release for every fix.

Answer 3

Seems to obvious to say, but: a version numbers purpose is to let you easily determine what version of the software anyone is running.

If there is any chance of anyone having access to a particular iteration of the code, and not otherwise easily be able to determine a unique identifier, then that iteration should have a unique version number. I see this as the 'first rule'. As a consequence, distinct releases will clearly want distinct version numbers.

However, more comes into play:

One way to be sure of this is to bump version numbers with each commit but this is not usually a good idea. It may take several commits/iterations to get a relatively small change working, and it's confusing to the outside world to see version 0.0.1 -> 0.0.2 as a result of a large number of accumulated changes then 0.0.2 -> 0.0.56 because someone committed white space fixes one file at a time and didn't change anything functional.

How far down the road from "one version per full release" to "one version for each commit" is really up to: you, the other users, and what systems you're willing to use to fill the gaps.

I personally am used to working on small projects, and am happy to use git hashes until a version that others use and a bump version for each of these (no matter how few people I am expecting to get their hands on it). However in larger companies and larger projects something outside semantic version numbers, but lower fidelity than each commit, like release candidate numbering is used. These have advantages but add complexity.

Answer 4

Every pull request that gets merged to master should be versioned.

If it shouldn't be a new version (at least a patch), it likely shouldn't be merged to master because the feature/fix/etc is not complete.

However, depending on your team's workflow you still might end up with multiple commits to master without a version. If there are several commits in a pull request that do not get squashed (They shouldn't in my opinion), you may still end up with 10 commits and just 1 new version.