Change Request: Prepare infrastructure for v9 prereleases

[mdjermanovic]

ESLint version

main

What problem do you want to solve?

Since the last major release, there have been many changes in ESLint projects. Notably, built-in configurations have been extracted into a separate package @eslint/js, we have a new eslint.org site with underlying docs sites for different versions, some projects are using release-please, and we switched to conventional commits.

It doesn't seem that all parts of our infrastructure support prereleases.

In particular:

• Jenkins
  • The job for @eslint/js doesn't provide a way to choose a prerelease type and publish the package with the next tag.
• release-please
  • We'll have a breaking change in @eslint/eslintrc (feat!: Set default schema: [], drop support for function-style rules eslintrc#139). Do we want to publish a v3 prerelease first? I think it's fine to just publish regular v3.0.0 right away, but if we want prereleases we'll need to figure out how to publish preleases with release-please.
• Conventional commits
  • It doesn't seem that eslint-release supports docs! tags, so we'll need to either update eslint-release or merge those commits as just docs.
• eslint.org site
  • On the homepage, the "Latest Version" should probably stay at v8.56.0, and we might want to also show the latest prerelease version (the version that is next on npm).
• docs sites
  • We should create next branch, set up Netlify, and update redirects for /docs/next/
  • Ideally, all three docs sites (head, next, latest) should have the following list in version selectors: HEAD, NEXT, v8.56.0. Most of the work for this was already done in 6669413, but we'll probably also need to manually update the latest branch, and I'm not sure if v9.0.0-alpha.0 will mistakenly appear instead of v8.56.0 on HEAD and NEXT docs sites.

What do you think is the correct solution?

Update the infrastructure for prereleases according to the points above.

Participation

• I am willing to submit a pull request for this change.

Additional comments

Is there anything else that should be updated?

[nzakas]

* Jenkins
  
  * The job for `@eslint/js` doesn't provide a way to choose a prerelease type and publish the package with the `next` tag.

Makes sense.

* release-please
  
  * We'll have a breaking change in `@eslint/eslintrc` ([feat!: Set default `schema: []`, drop support for function-style rules eslintrc#139](https://github.com/eslint/eslintrc/pull/139)). Do we want to publish a v3 prerelease first? I think it's fine to just publish regular v3.0.0 right away, but if we want prereleases we'll need to figure out how to publish preleases with release-please.

We generally have not created prereleases of anything other than eslint, so I'm fine with just going to v3.0.0 directly.

* Conventional commits
  
  * It [doesn't seem](https://github.com/eslint/eslint-release/blob/c55858f6de1d2d6c7b58a1817b3af5ea59e65fc8/lib/release-ops.js#L30-L46) that eslint-release supports `docs!` tags, so we'll need to either update eslint-release or merge those commits as just `docs`.

oops, good call. I think just renaming to docs is fine.

* eslint.org site
  
  * On the homepage, the "Latest Version" should probably stay at v8.56.0, and we might want to also show the latest prerelease version (the version that is `next` on npm).

True. I'd suggest that after we release the alpha, we hide "development" and replace it with the current prerelease version. So instead of "Latest Version", "Upcoming Version", and "Development", we have "Latest Version", "Latest Prerelease Version", and "Upcoming Version". That way, we don't mess up the layout by adding a fourth data point.

* docs sites
  
  * We should create `next` branch, set up Netlify, and update [redirects](https://github.com/eslint/eslint.org/blob/main/src/static/redirects.njk) for `/docs/next/`
  * Ideally, all three docs sites (head, next, latest) should have the following list in version selectors: HEAD, NEXT, v8.56.0. Most of the work for this was already done in [6669413](https://github.com/eslint/eslint/commit/66694136b67277c050bd27f60050779687a88c9f), but we'll probably also need to manually update the `latest` branch, and I'm not sure if v9.0.0-alpha.0 will mistakenly appear instead of v8.56.0 on HEAD and NEXT docs sites.

Yeah, I was thinking we could create a file in the main branch that contains that data, and update the generation of the dropdown so it always pulls from the file in main instead of a file in the current branch. I think that would allow us to more easily make this change.

[mdjermanovic]

* eslint.org site
  
  * On the homepage, the "Latest Version" should probably stay at v8.56.0, and we might want to also show the latest prerelease version (the version that is `next` on npm).

True. I'd suggest that after we release the alpha, we hide "development" and replace it with the current prerelease version. So instead of "Latest Version", "Upcoming Version", and "Development", we have "Latest Version", "Latest Prerelease Version", and "Upcoming Version". That way, we don't mess up the layout by adding a fourth data point.

I'm working on this.

[mdjermanovic]

* docs sites
  
  * We should create `next` branch, set up Netlify, and update [redirects](https://github.com/eslint/eslint.org/blob/main/src/static/redirects.njk) for `/docs/next/`
  * Ideally, all three docs sites (head, next, latest) should have the following list in version selectors: HEAD, NEXT, v8.56.0. Most of the work for this was already done in [6669413](https://github.com/eslint/eslint/commit/66694136b67277c050bd27f60050779687a88c9f), but we'll probably also need to manually update the `latest` branch, and I'm not sure if v9.0.0-alpha.0 will mistakenly appear instead of v8.56.0 on HEAD and NEXT docs sites.

Yeah, I was thinking we could create a file in the main branch that contains that data, and update the generation of the dropdown so it always pulls from the file in main instead of a file in the current branch. I think that would allow us to more easily make this change.

We might need to fetch that file in the browser, because the sites are static and I'm not sure if we'd want to rebuild all the sites whenever we release a new version. Since we have very little time until the next release, I'll try to update what we already have a bit just to achieve HEAD, NEXT, v8.56.0 on the three docs sites we have at the moment, and I'll open another issue to discuss a long-term solution.

[mdjermanovic]

Looks like function generatePrerelease hasn't been updated for the new docs site, and that's why 9.0.0-alpha.0 release didn't update any files in the docs directory. I'm working on that.

[mdjermanovic]

All tasks are done, and there's a separate issue for a better, long-term solution for version lists (#17943), so I think we can close this now.

I'll check if some changes should be made for the prerelease -> release step and open a new issue if I find anything.