-
-
Notifications
You must be signed in to change notification settings - Fork 6
Conversation
@@ -6,17 +6,9 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0 | |||
|
|||
## [Unreleased] | |||
|
|||
## [1.0.1] |
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.
Would be better to mark it as (RETRACTED)
or similar, rather than removing - if there's something acceptable that will pass changelog lint
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.
Usually we do something like
## [1.0.1] - [DEPRECATED]
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.
Would be better to mark it as
(RETRACTED)
or similar, rather than removing - if there's something acceptable that will pass changelog lint
Yeah, absolutely — even if we are retracting a version, we still ought to keep it in the changelog for posterity. I believe that auto-changelog
should be okay with any text added after a version number. We have a precedent for adding a [DEPRECATED]
tag here: https://github.com/MetaMask/eth-sig-util/blob/main/CHANGELOG.md#500-deprecated (EDIT: Mark got there first 😅 )
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.
The main reason we leave these releases in the changelog is that npm provides no way to pull them in most cases. We can't retract it from npm even if we wanted to, but we can mark it as deprecated.
package.json
Outdated
@@ -1,6 +1,6 @@ | |||
{ | |||
"name": "@metamask/eth-json-rpc-provider", | |||
"version": "1.0.1", | |||
"version": "1.0.0", |
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.
@legobeat I see that this PR changes the version from 1.0.1 to 1.0.0. While we could do that, since we are publishing 2.0.0 anyway, I wonder if it would be easier to keep it at 1.0.1 and only update the changelog to indicate that this version has been deprecated. We could also deprecate 1.0.1 on NPM itself (using npm deprecate
). Then we could bump the version to 2.0.0 and release 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.
You're right; updating accordingly.
v1.0.1 contains two changes that should have been considered semver-major: - Type-interface incompatability with previous version (MetaMask/json-rpc-engine#139) - Introduced dependency `@metamask/json-rpc-engine` indicates a minimum supported Node.js version of 16. This prevents the module from installing on some package manager configurations, like default yarn classic. This will be re-released as v2.0.0.
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.
Looks good.
v1.0.1 contains two changes that should have been considered semver-major:
@metamask/json-rpc-engine
indicates a minimum supported Node.js version of 16. This prevents the module from installing on some package manager configurations, like default yarn classic.This will be re-released as v2.0.0.