build: Support updates to previous major versions#18870
Conversation
|
Looks like some transitive dependencies of |
|
I added |
|
Now it seems that |
|
Okay, adding
|
|
This is marked as draft because it needs a new version of |
I'd say it's okay considering that we won't be dealing much longer with the v8 branch. FWIW, I tried dowgrading |
Good to know, will keep that as a backup option if CI breaks in the following days. |
✅ Deploy Preview for docs-eslint ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
| */ | ||
| function generateRelease() { | ||
| ReleaseOps.generateRelease(); | ||
| function generateRelease({ packageTag }) { |
There was a problem hiding this comment.
Sanity check: Is this function signature intentionally different than the one in #18871?
There was a problem hiding this comment.
Yes, we had (and still have on this branch) separate functions function generateRelease and function generatePrerelease which were later in the main branch merged into one (c2bf27d).
|
|
||
| exec(`git checkout ${MAIN_GIT_BRANCH} --force`); | ||
|
|
||
| fs.writeFileSync(CHANGELOG_FILE, `${releaseInfo.markdownChangelog}${cat(CHANGELOG_FILE)}`); |
There was a problem hiding this comment.
This will insert the changelog updates for the new maintenance release on top of the changelog on the main branch, right? Will users understand to which previous release those changes were applied upon, or would it make sense to indicate the branch name along with the version number (e.g. v8.57.1 on v8.x-dev)? I am looking at the changelog updates for v8.57.0 that was published sometime during the v9 pre-release phase, and now it's not obvious at what point the v8 and v9 branches diverged.
There was a problem hiding this comment.
This will insert the changelog updates for the new maintenance release on top of the changelog on the main branch, right?
Yes, the idea was to order the releases chronologically, not according to semver rules.
Will users understand to which previous release those changes were applied upon, or would it make sense to indicate the branch name along with the version number (e.g. v8.57.1 on v8.x-dev)? I am looking at the changelog updates for v8.57.0 that was published sometime during the v9 pre-release phase, and now it's not obvious at what point the v8 and v9 branches diverged.
I think this can be easily figured out from the commit history and tags, but open for other solutions. I believe it isn't a common practice to mention branches as they could be temporary and the process could change over time, but maybe we could add a link to the tag: https://github.com/eslint/eslint/tree/v8.57.0.
@nzakas what do you think?
There was a problem hiding this comment.
I think it's fine as-is. Realistically, I don't know how many people are going be looking at CHANGELOG.md on its own and trying to figure out releases from there. I think it's more likely that people will either view it via a commit that just shows the new entries or will look at GitHub releases or blog posts.
All that is to say: I don't think it's necessary to mention a tag or branch. People who really care will be able to figure out where to go to get that information.
This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [eslint](https://eslint.org) ([source](https://github.com/eslint/eslint)) | devDependencies | patch | [`8.57.0` -> `8.57.1`](https://renovatebot.com/diffs/npm/eslint/8.57.0/8.57.1) | --- ### Release Notes <details> <summary>eslint/eslint (eslint)</summary> ### [`v8.57.1`](https://github.com/eslint/eslint/releases/tag/v8.57.1) [Compare Source](eslint/eslint@v8.57.0...v8.57.1) #### Bug Fixes - [`a19072f`](eslint/eslint@a19072f) fix: add logic to handle fixTypes in the lintText() method ([#​18900](eslint/eslint#18900)) (Francesco Trotta) - [`04c7188`](eslint/eslint@04c7188) fix: Don't lint same file multiple times ([#​18899](eslint/eslint#18899)) (Francesco Trotta) - [`87ec3c4`](eslint/eslint@87ec3c4) fix: do not throw when defining a global named `__defineSetter__` ([#​18898](eslint/eslint#18898)) (Francesco Trotta) - [`60a1267`](eslint/eslint@60a1267) fix: Provide helpful error message for nullish configs ([#​18889](eslint/eslint#18889)) (Milos Djermanovic) - [`a0dea8e`](eslint/eslint@a0dea8e) fix: allow `name` in global ignores, fix `--no-ignore` for non-global ([#​18875](eslint/eslint#18875)) (Milos Djermanovic) - [`3836bb4`](eslint/eslint@3836bb4) fix: do not crash on error in `fs.walk` filter ([#​18886](eslint/eslint#18886)) (Milos Djermanovic) - [`2dec349`](eslint/eslint@2dec349) fix: skip processor code blocks that match only universal patterns ([#​18880](eslint/eslint#18880)) (Milos Djermanovic) #### Documentation - [`6a5add4`](eslint/eslint@6a5add4) docs: v8.x Add EOL banner ([#​18744](eslint/eslint#18744)) (Amaresh S M) - [`b034575`](eslint/eslint@b034575) docs: v8.x add version support page to the dropdown ([#​18731](eslint/eslint#18731)) (Amaresh S M) - [`760ef7d`](eslint/eslint@760ef7d) docs: v8.x add version support page in the side navbar ([#​18740](eslint/eslint#18740)) (Amaresh S M) - [`428b7ea`](eslint/eslint@428b7ea) docs: Add Powered by Algolia label to the search ([#​18658](eslint/eslint#18658)) (Amaresh S M) - [`c68c07f`](eslint/eslint@c68c07f) docs: version selectors synchronization ([#​18265](eslint/eslint#18265)) (Milos Djermanovic) #### Build Related - [`35d366a`](eslint/eslint@35d366a) build: Support updates to previous major versions ([#​18870](eslint/eslint#18870)) (Milos Djermanovic) #### Chores - [`140ec45`](eslint/eslint@140ec45) chore: upgrade [@​eslint/js](https://github.com/eslint/js)[@​8](https://github.com/8).57.1 ([#​18913](eslint/eslint#18913)) (Milos Djermanovic) - [`bcdfc04`](eslint/eslint@bcdfc04) chore: package.json update for [@​eslint/js](https://github.com/eslint/js) release (Jenkins) - [`3f6ce8d`](eslint/eslint@3f6ce8d) chore: pin [email protected] ([#​18910](eslint/eslint#18910)) (Milos Djermanovic) - [`9f07549`](eslint/eslint@9f07549) chore: ignore `/docs/v8.x` in link checker ([#​18660](eslint/eslint#18660)) (Milos Djermanovic) </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOC44MC4wIiwidXBkYXRlZEluVmVyIjoiMzguODAuMCIsInRhcmdldEJyYW5jaCI6ImRldmVsb3AiLCJsYWJlbHMiOlsidHlwZS9kZXBlbmRlbmNpZXMiXX0=--> Reviewed-on: https://git.vylpes.xyz/External/card-drop/pulls/366 Reviewed-by: Vylpes <[email protected]> Co-authored-by: Renovate Bot <[email protected]> Co-committed-by: Renovate Bot <[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
v8.x-devbranch to support new v8.x releases.What 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 thev8.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 also updatedocs/src/_data/versions.jsonon themainbranch.Is there anything you'd like reviewers to focus on?
Some changes are unnecessary for this branch (e.g., we'll never release another
latestfrom it) and many things could have been hardcoded, but I wanted to make this roughly the same as changes that will be done in themainbranch (#18871) for testing purposes and easier review.I tested this locally (just had to replace remote commands like
git push...withecho git push...) on thev8.x-devbranch and it seems to be working fine.