[cbdfghh]

> I like the idea of Semantic Versioning, but it does cause problems where if I'm going to do several breaking releases one after another I have to keep bumping the major version, and I hate that. I've actually put off doing breaking changes simply because I didn't want to bump the major version number, but I don't like that either.

When you're doing backend/API things (where breaking changes matter), I sure hope you think a million times before making breaking changes.

Can you imagine if someone had to go through millions of lines of his code to make sure nothing broke, then, a week later, you broke his code again?

[thomaslee]

I'm not the parent, but I sort of like the idea at first glance. I mean, it's a fine line: if I have "v1.0.0" and I break one API in one module, I'm compelled to release "v2.0.0" even though v2.0.0 is otherwise entirely compatible with v1 -- it's not as big of an upgrade as the version numbering system would imply.

But if I go and drastically change things in a way likely to impact many users, that gets a brand new version number too. So v1.0.0 -> v2.0.0 only really communicates "something might break".

The scheme proposed by the parent would be able to communicate "expect many things to break because I refactored the heck out of stuff to fix some long-standing design deficiencies" -- though admittedly when to bump that first version number is likely to be a subjective topic. :)

Perhaps this isn't as valuable as it seems at a first glance, but if anybody's tried something like this I for one would be interested to hear about it.

[pixel_fcker]

A piece of software I'm familiar with does this Arch.Major.Minor.Patch.

The Arch number represents a "generation" of the software that represents a significant overhaul where the architecture changes and input files that were generated for previous versions are not likely to work.

Major represents breaking API compatibility, so users who write plugins for the software will need to recompile and possibly change their code (but maybe not depending on what changed).

Minor and Patch are what you'd expect from semver.

This works extremely well from my experience.

[humanrebar]

The point of making backwards compatibility the first number is because the subtle changes need attention drawn to them. There's little risk of people accidentally using things in a broken way when projects are renamed. It's about clarity of technical communication. There are lots of ways to communicate big direction changes, including changing the look and feel of something, adding code words (WD Caviar Green), putting out a big publicity push (v32 is a whole new game!), and so on.