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.
1 Like
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.
Big +1
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.
2 Likes