-
Notifications
You must be signed in to change notification settings - Fork 30.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Package versioning (divergence, breaking changes, etc) #34047
Comments
One of the motivations behind the current versioning scheme is discoverability. By correlating the "major" and "minor" segments of a types-package version to its related package version, we make it much easier to discover the correct types for a package. For example, if you were creating a project that uses npm i react@15
npm i -D @types/react@15 Under the current versioning scheme, we use the "patch" segment to indicate changes to the types package itself. If you are concerned about a types package having significant changes, then you would avoid using a caret ( Alternative: Use a "pre-release" VersionIn these versioning schemes,
|
I understand. Your suggestion of Do you understand why it doesn't satisfy caret versioning? Maybe im just being blind but it looks like it should. It would be much better than what we do now, though. We ship so many breaking changes because of people fighting semver, it'd be a lot smoother if we didn't have that state of mind. |
Coming from a Rust / .NET point of view I've seen libraries that provide FFI bindings to other libraries use some SemVer that includes the major and minor version of the 'target' library in the 'client' library's major version. e.g: For bindings to LLVM 7.0 you could have a semver of This approach doesn't come without its own set of problems however. |
Here's a few examples of that approach: https://crates.io/crates/llvm-sys#llvm-compatibility |
Here is some previous discussion of the problem: |
Hi thread, we're moving DefinitelyTyped to use GitHub Discussions for conversations the To help with the transition, we're closing all issues which haven't had activity in the last 6 months, which includes this issue. If you think closing this issue is a mistake, please pop into the TypeScript Community Discord and mention the issue in the |
As seen in #33666 and many other PRs, I have noticed we often compromise on strong versioning to maintain synchronisation with source package versions.
An example, again, is #33666. Unfortunately, the types were incorrect throughout so fixing them would require a breaking change. However, the source package has no such major version, so we would diverge and have two different versions.
I have seen this happen often, not always noticed by us under code review.
I think, because we present the versions as being "in sync" and because that is commonly the case, people will choose to avoid following semver correctly and rather choose to strictly match the source version.
IMO we should be moving more towards promoting the idea of understanding that the two versions are not the same, the two packages are two distinct, separate packages.
We should recommend that new types start at
1.0
, regardless of the source package's version. This and making it very clear that version bumps are fine and can diverge.This would lead to the types following semver in a much smoother and stricter fashion, i think.
I believe the whole concept of coupled-versions is damaging the reliability and quality of this repo and is leading people to go against common sense/good practice.
I suspect most of the stealth-breaking-changes (patch/minor version bumps) that go out and cause issues to be opened are made because people don't want to increment the version.
/cc @sandersn @RyanCavanaugh @rbuckton
The text was updated successfully, but these errors were encountered: