RELEASE.md

Release steps

1. create a release-[x.y.z] branch from tip of main (or whatever release commit)

   git checkout main && git pull && git checkout -b release-2.1.0

2. bump package.json + update CHANGELOG version links for all releasing packages (i.e., root + any resolvers)

   In changelog for core plugin, normally leave [Unreleased] but update its link at the bottom to be rooted at the new version's tag, and add a link for the new version rooted at last version's tag.

   [Unreleased]: https://github.com/import-js/eslint-plugin-import/compare/v2.0.1...HEAD
   [2.0.1]: https://github.com/import-js/eslint-plugin-import/compare/v2.0.0...v2.0.1

   becomes

   [Unreleased]: https://github.com/import-js/eslint-plugin-import/compare/v2.1.0...HEAD
   [2.1.0]: https://github.com/import-js/eslint-plugin-import/compare/v2.0.1...v2.1.0
   [2.0.1]: https://github.com/import-js/eslint-plugin-import/compare/v2.0.0...v2.0.1

   Generally, don't use npm version for this because it creates a tag, which I normally wait until signoff from contributors and actually npm publish-ing to snap the tag.

3. create pull request from release-[x.y.z] into release branch

   I like this because it

   • lists all commits in the release
   • provides a commentary location to discuss the release
   • builds in CI and provides test results

4. iterate on feedback

   • handle other issues
   • merge more PRs
   • fix issues in changelog/docs

5. npm publish from release-[x.y.z] branch

   • don't forget resolvers!

6. tag commit (v[x.y.z])

   • again, not forgetting resolvers, if needed (resolvers/[name]/v[t.u.v])

7. merge release-[x.y.z] into release (

   • ideally fast-forward, probably with Git CLI instead of Github

8. merge release into main

Done!