[Hackbraten]

I feel that both variants have their merits.

One possible downside (of version bumping immediately after release) is that if you use the major/minor/patch scheme, you can never be sure that you’re actually bumping the correct number. The upcoming release may be a major, a minor, or a patch release, and it might take you a while until you know enough about completed work items so you can make up your mind which one it’s going to be.

[tjoff]

Not sure why that is a downside? Once you realize you need to update minor or whatever then update it, done. As a bonus you have great visibility into why and when the minor needed to update.

[OJFord]

One complexity with that that comes to mind is how do you then track whether you've already bumped minor/major since last release and so don't need to again? Maybe it's rare enough and quick enough to manually check that that's not a problem, depends on the project I suppose.

[anonymous_sorry]

> One complexity with that that comes to mind is how do you then track whether you've already bumped minor/major since last release and so don't need to again?

I wonder if it really matters that release version numbers only increment by one. If not, just bump anyway when appropriate change is made - no need to check.

In practice I think the problems would be a) having to be very disciplined about this on every commit, rather than having a reminder to consider it as part of a release process, and b) ordering version numbers from different branches when merging to mainline

[OJFord]

True, that'd be a decent way to approach it. Though at that point perhaps you may as well actually release all the versions too.

Or you could bump every time as you describe, but on every major/minor bump make sure the parent commit is released first (which would be >=1 commits since the last one and have at least a patch bump). And I suppose you'd never need to bump patch if that was just a lone thing that happened post-release in prep for the next.

[CameronNemo]

As opposed to having to track later when you bump the version whether you need a patch/minor/major bump?

Seems like any way you do it you have to keep track. IMO version numbers are slightly easier to keep track of than breaking changes. Changelogs are not always structured.

[Vinnl]

If you do it at the time of bumping, you can just look at the then-current version number to decide what new version a major, minor or patch release will result in. If you do it the moment you introduce e.g. a breaking change, you'll have to check whether this is the first breaking change since the last release (i.e. keep the set version number as-is), or if the one that it's currently set to is what it should be.

Minor annoyance, but still.

[azundo]

We do this by looking at the patch version. For example, current version in source is 2.2.1-alpha0. This means the last bump was a patch version from 2.2.0 to 2.2.1, so if you want a minor bump, then you need to bump to 2.3.0-alpha0. Now that the patch version is 0, it's that someone has already bumped the minor version since the last release, so no need to do so again. This would break down if someone bumps to 2.3.1-alpha0 unnecessarily but otherwise it's immediately obvious looking at the current version in source whether someone has already bumped the minor version.

[Vinnl]

Ah, that makes sense!

[CameronNemo]

Yes, but what I am saying it is way easier to go back and look at what the most recent release was (most SCMs have a page for all the tags, and there is git tag), but it is harder to go back and figure out if you had breaking changes (would need to use conventional commits or similar, then parse the gitlog or structured changelog).

[Vinnl]

You'll have to figure out if you had breaking changes regardless of when you change the version number, no? My strategy there is to add to the 'unreleased' section of the changelog as they are introduced.

[usrusr]

The number you already bumped is the one followed by ([.]0)*$

Assuming that you do a strict hierarchical versioning scheme and not some multidimensional thing where numbers increment independent from each other.