build: Support updates to previous major versions #18871
Conversation
✅ Deploy Preview for docs-eslint ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
This is marked as draft because it needs a new version of |
docs/src/maintain/manage-releases.md
Outdated
|
|
||
| The following table shows examples of the option to select as `RELEASE_TYPE` when starting `eslint-js Release` (the `@eslint/js` package release) and `eslint Release` (the `eslint` package release) jobs on Jenkins to release a new version with the latest features. In both jobs, `main` should be selected as `RELEASE_BRANCH`. | ||
|
|
||
| | **Current version** | **Releasing** | **`eslint-js Release`** | **`eslint Release`** | |
There was a problem hiding this comment.
I'm having a bit of trouble understanding this table. Is "Current Version" the equivalent of eslint@latest? I'm also not clear on what the "Releasing" column is meant to indicate. Is that the desired next version?
There was a problem hiding this comment.
Is "Current Version" the equivalent of
eslint@latest?
No, "Current Version" is as described on https://eslint.org/version-support/. For example, when we released 9.0.0-alpha.0, 9.0.0-alpha.0 became the "Current Version".
I'm also not clear on what the "Releasing" column is meant to indicate. Is that the desired next version?
Yes, that's the version that is going to be released.
Any ideas for better names to clarify this?
There was a problem hiding this comment.
Ah ok. "Current" on the version support page refers to the major release line, not a single version.
Looking this over, I think it's confusing to combine settings for eslint and @eslint/js in the same table. For ESLint, we cannot guarantee that 9.25.0 goes to 9.25.1 because it depends on the commits. I think it may be better to separate these into two tables, one for eslint and one for @eslint/js.
As for the wording, maybe this?
- "HEAD Version"
- "Desired Next Version"
eslintRelease Option
docs/src/maintain/manage-releases.md
Outdated
|
|
||
| When releasing a new version of the previous major line, the option to select as `RELEASE_TYPE` depends on whether the current version is a prerelease or not. In both jobs, the corresponding development branch (for example, `v9.x-dev`) should be selected as `RELEASE_BRANCH`. | ||
|
|
||
| | **Current version** | **Releasing** | **`eslint-js Release`** | **`eslint Release`** | |
There was a problem hiding this comment.
Same comment here. I find this format hard to understand.
Co-authored-by: Nitin Kumar <[email protected]>
Prerequisites checklist
What is the purpose of this pull request? (put an "X" next to an item)
[ ] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofix to a rule
[ ] Add a CLI option
[ ] Add something to the core
[x] Other, please explain:
Refs #18691
Updates
mainbranch to support releasing updates to previous major versionsWhat changes did you make? (Give an overview)
release:generate:maintenancescript. When this script is run, Makefile.js will pass package tag"maintenance"to eslint-release, which will then publish new release with--tag maintenanceon npm and also not mark it as Latest on GitHub (feat: Support updates to previous major versions eslint-release#62). Also, Makefile.js will update avNN.xdocs branch instead of thelatestdocs branch. We'd addmaintenanceto the RELEASE_TYPE list on Jenkins.main, Makefile.js will copy over the changelog update to themainbranch, and updatedocs/src/_data/versions.jsonon themainbranch instead of the current branch.Is there anything you'd like reviewers to focus on?
I tested this locally (just had to replace remote commands like
git push...withecho git push...) on themainbranch (including the case when v8.57.1 has already been released from thev8.x-devbranch) and a futurev9.x-devbranch with various scenarios and everything seems to be working fine.