chore: bump package.json versions, mostly for canary release versioning#11980
Merged
Conversation
✅ [V2]
To edit notification comments on pull requests, go to your Netlify project configuration. |
⚡️ Lighthouse report for the deploy preview of this PR
|
|
Size Change: 0 B Total Size: 12 MB ℹ️ View Unchanged
|
|
No dependency changes detected. Learn more about Socket for GitHub. 👍 No dependency changes detected in pull request |
|
Size Change: 0 B Total Size: 12.5 MB ℹ️ View Unchanged
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
Bump
package.jsonfor canary versioning like we always had before, using the latest minor version as a base.It's not ideal, but otherwise we need to find a better way to implement our new supply chain workflow (#11874) since it expects the version numbers we use to already be on npm.
Motivation Legacy
**This was the goal, but finally not implemented 😅 **
The version in our monorepo
package.jsonfiles is not really "useful" because we always explicitly define it as part of our new Trusted Publishing workflow.However, having the wrong version can remain a problem:
mainFor that reason, I think we should bump that version number of all monorepo packages to the next release we plan to do, in this case v4.0.0, so that canary releases clearly indicate with versioning that they contain breaking changes.
I've also considered adding a
canaryVersion: "4.0.0"in our monorepopackage.json, but it still remains confusing for contributors to see3.9.2onmainso it seems better to just bump these version numbers as part of our release process.Note: it's not a big deal if you don't know whether the next release is a minor/major version: