Releasing a new version
A GH Action allows you to create a new release of @elastic/charts thanks to semantic-release: the release version and change logs will be automatically generated from the commits available in master between the latest release tag and the current HEAD. This procedure will publish the new version in the NPM registry.
To release: Go to Actions -> Publish release -> Run Workflow on master branch and press Run
The same GH Action used to publish a new release can be used to publish a backported PR by selecting the backported branch in the Run Workflow dropdown menu.
If a bad package was released to npm we have 3 options, depending of severity. For major problems that were caught early (<72hrs), we should attempt to unpublish the bad package version. In the case we cannot unpublish or for minor issues we can deprecate the package version. The last option is to just release a patch version off of the bad version but leave the bad version in place.
First we need to try to unpublish the bad package on npm.
# npm unpublish <package_name>@<version>
$ npm unpublish @elastic/[email protected]If the unpublish fails it's likely too old or too widely used, see unpublish policy.
In such case we can simply deprecate the package instead.
# npm deprecate <package-spec> <message>
$ npm deprecate @elastic/[email protected] "This version is bad because..."Important
These commands are run locally, as such, you will need permissions to access the npm elastic org.
No need to unpublish or deprecate anything in npm, just release a patched version.
If there was an issue with the commit message we should update this commit in the release branch (i.e. main) and force push to fix the upstream branch. If we don't fix this, semantic release may throw an error.
If there is no issue with the commit message, you should simply add your changes in a patch commit.
Finally, be sure to remove the semantic-release-bot commit which upgrades the package version (i.e. 8f6872f22191703c8170e2178b01da3b4bba4223).
If you were able to unpublish the bad version, we should delete it from our GitHub releases.
Use the GitHub UI to delete the release. We should also delete the related tag. The tag is no longer needed to link to the release, but also in the case we want to release the same version, the semantic-release-bot requires all aspects of the old release to be gone otherwise it will throw an error and fail to release.
If you were not able to unpublish the release and opted to deprecate it instead, we should note this on the bad release in GitHub. See an example of this here.
After making all the necessary corrections above, we can publish a new release.