Agreed it's not a new idea, but I'm not discounting adding a catchy name to it and a well-made website with a clear specification. That will get people using it in some open-source communities (Node / JavaScript specifically).

The problem with SemVer is that library owners are not strict with its intended usage (backwards incompatible changes in patch!) or don't fully understand it. Perhaps having a much more simple versioning strategy will help in some use cases.

Sorry for the super late followup, but yeah my point was a pretty good selling point might be its been an operationally useful, apparently optimized, and successful solution for many decades in the fields of X, Y, and Z, and the more examples of success, the better.

> The problem with SemVer is that library owners are not strict with its intended usage

The worst case I saw was when someone was just appending 9's to the version number every release (0.99999 -> 0.999999). I think this was a joke about asymptotically approaching version 1.0. The effect was that some error message when solving dependencies came out as "X wants version 0.99999999999, but Y wants version 0.99999999999". Very annoying!

> The problem with SemVer is that library owners are not strict with its intended usage

What's the point of doing it if you're not gonna do it right?

Thanks for the kind words!

I was eight years old in '96. I wish this versioning strategy caught on then.

Maybe I should add a "prior art" section on the site, thanks for the link!