[CuriousCosmic]

I don't think that's really necessarily fair.

A major version of zero means pre-release code. i.e. a codebase under active development (with the implicit assumption that there will likely be major breaking changes).

A major version of zero just means "I am not committing to a stable API until 1.0" which is a completely fair stance. I'm not going to write code that's very clearly unstable and in active churn and try to pretend it's stable. I'm also not going to keep around a legacy API at that point yet.

Compare that to a standard bump in major version (i.e. 1.0 to 2.0). In this case there is an expectation of a migration path and in all likelihood a versioned legacy API that'll stick around so that users can slowly migrate across the breaking changes between API versions.

Frankly I'm not going to commit to doing that for 0.X.Y/indev projects.

[krainboltgreene]

> i.e. a codebase under active development (with the implicit assumption that there will likely be major breaking changes).

You have just described all actively written software as "major zero". This is why it's a silly concept.

[CuriousCosmic]

If you aren't committing to an API or ABI then why are you even releasing with SemVar. If you are releasing a piece of software without a stable interface just release it with date as a version (ex: yyyy.mm.dd).

SemVar makes sense but every piece of software using it doesn't. Not every piece of software makes an interface commitment. Those that do should use SemVar, the rest should just use the date or some monotonically increasing number.