-
Notifications
You must be signed in to change notification settings - Fork 2.7k
introduce a versioning policy for Apollo Client #12850
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
Conversation
🦋 Changeset detectedLatest commit: 575cc23 The changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
| "access": "public" | ||
| }, | ||
| "files": [ | ||
| "LICENSE", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
commit: |
size-limit report 📦
|
✅ Docs preview readyThe preview is ready to be viewed. View the preview File Changes 30 new, 64 changed, 7 removedBuild ID: 9b7c37a39ab8202710e2b281 URL: https://www.apollographql.com/docs/deploy-preview/9b7c37a39ab8202710e2b281 |
VERSIONING.md
Outdated
| - [`FinalizationRegistry`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/FinalizationRegistry) (already used by dependencies) | ||
| - [`Proxy`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy) | ||
|
|
||
| ## Dependencies |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we also add a section about TypeScript types here, noting that sometimes changes to types that are perceived as "breaking" are necessary, and we might consider them, and that we can uphold semver only for runtime code, not for TS types?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes I would. Perhaps something like:
We reserve the right to update TypeScript types as needed, such as to fix bugs or add compatibility with various TypeScript features. Updates to types might requires changes to your application, but we do not consider these breaking changes.
Feel free to workshop that 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
added a section :)
jerelmiller
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Had a few suggestions, but great overall! Really awesome to get this out there 🙂
VERSIONING.md
Outdated
|
|
||
| ### other dependencies | ||
|
|
||
| We reserve the right to update dependencies in minor releases of Apollo Client, as well as dropping support for older versions of dependencies. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we add a statement specifically about peer dependencies in general? Perhaps maybe that should be its own section? Its unclear whether "dependencies" in this context refer to peer deps or just regular deps.
In other words, do we guarantee that we won't require new peer dependencies in a major release cycle, or do we want the freedom to be able to add peer dependencies?
This probably deserves its own title right above this section with a statement about it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moving that under "Other", since it will reference rules above it.
Co-authored-by: Jerel Miller <jerelmiller@gmail.com>
| @@ -0,0 +1,93 @@ | |||
| # Apollo Client Versioning Policy | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rename to VERSIONING_POLICY.md

Out of the scope for this document, but a recommended read - this is how Ember defines SemVer in the context of TS types: https://rfcs.emberjs.com/id/0730-semver-for-ts/