0.x.y not a violation of semvar, but also not giving us the benefit of semvar. the 0 major version in semvar is there assuming there's an eventual convergence of features which leads to a version 1.
I think if we simply increase the major version number whenever a source breaking change occurs, it not only gives us the benefit of semvar (should I upgrade? oh, I can because major version didn't change!), but also tells a clear story about the nature of the library (oh, it went from major version x to x + 12 in a year!)
Based on the proposal, it sounds like we'll have that:
So, if you peg to a minor version, you'll be able to upgrade across patches without any hassle. The constant addition and one-year removal timeline of API from this package makes fully-fledged semver somewhat inappropriate. Major version N would almost certainly be disjoint from major version N+M for even moderately large values of M.
The semver rules for version 0 make no mention of convergence:
Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.
This package will be in a constant stage of "initial development". To me, increasing major version numbers tells a story that much more strongly implies some sort of convergence.
Sure, I think everyone understands the facts here. It's just not clear to me what the benefit is of effectively making the minor version equivalent to a major version, and the patch version equivalent to both minor & patch versions. Is that better than just versioning it properly, and maybe additionally recommending people use it as a branch-based dependency if they want to stick to the latest version? Why? As I said previously, I don't believe the package manager has any special treatment of 0.y.z versions, so it is not going to know anything useful about the distinction the proposal draws between minor and patch versions.
Totally agree with this one, many features of Swift have to be delayed until version bumps and later on integrated in projects. I'm totally in with this one.
Only thing Iām not sure about is keeping functionality a whole year after it appears in the released library. Some might start treating it as a backport package instead of a preview. Then there may be backlash against removing certain features even after the year is over.
I think it makes sense to say that this package is appropriate for users who are committed to upgrading to the next version of Swift as soon as it comes out.
People can always pin their dependencies to the last version supported by their Swift version or copy and paste the functionality they need.