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