[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.

[OJFord]

GP's point (I think I agree now, I was only saying it was a potential issue) being that that's a lot easier to do at the time - you know you've just made a breaking change (or you should do; as much/more than you ever will) so that's the easiest time to bump the version appropriately.

An alternative model I suppose would immediately have major bump, minor bump, and patch bump branches; then you just commit to the appropriate one, and I suppose keep major rebased on minor rebased on patch. (And master = major I suppose.)

[Vinnl]

Right, but what if that was the second breaking change you made? To figure out whether that's the case, i.e. whether you need to bump the major version or not, you'll have to check out the last released version.