feat: source of truth for version support

[dsanders11]

🚧 Kicking this off for discussion.

Currently this information lives in a table in the e/e docs at docs/tutorial/electron-timelines.md, it was copied over directly (with dates tweaked to match expected format).

This PR pulls that data into this repo and exposes a new /support.json and /versions.json (which is just /support.json + /releases.json combined) to act as the single source of truth for this information. There are two generated fields, isSupported (true if the major is not EOL) and isStable (true if the vX.0.0 release exists for the major).

Doing this lets us remove the hardcoding in this repo added in #15 to keep E22 as a stable release, since now that is dynamically determined by the EOL date in src/versions-support.json.

🌎 The big picture idea is this information will be used in a bunch of places in downstream projects:

1. Create a new @electron/versions package which takes the Versions logic from @electron/fiddle-core and refactors to use /versions.json so that supported majors are not hardcoded
2. Update various bots to using the new @electron/versions package and remove the duplicated logic we have with a hardcoded number of supported versions:
   • electron/roller
   • electron/sudowoodo
   • electron/trop
   • electron/unreleased
3. Generate the documentation versions table (the source of this data) on electron/website
   • Currently it does not show v26, because it is showing the docs for v25. If we generate it based on this data, it will be updated each time the website does a deploy (regularly scheduled)
4. Update @electron/fiddle-core and Fiddle to use @electron/versions, ensuring that Fiddle accurately reflects supported majors
5. Use /support.json to pull the stable kickoff date when creating new release project boards on e/e
6. Migrate other repos using @electron/fiddle-core to find the latest stable release to using @electron/versions
   • electron/chromedriver
   • electron/mksnapshot

❓ Soliciting feedback on key names and the overall data shape here. Currently it's an array (similar to the existing /releases.json data shape) but it would also be reasonable to make it an object keyed by the major number, which is what Node.js does with their equivalent at https://github.com/nodejs/Release/blob/main/schedule.json.

Here's what the output for a given major looks like:

$ curl --silent http://localhost:8080/support.json | jq '.[] | select(.major==25)'
{
  "major": 25,
  "alpha": "2023-04-10",
  "beta": "2023-05-02",
  "stable": "2023-05-30",
  "endOfLife": "2023-12-05",
  "isSupported": true,
  "isStable": true
}

[MarshallOfSound]

These dates shouldn't need to be hardcoded, they can be auto-generated from historical release data? Unless the intention is that these are date predictions, in which case I'm not a huge fan of this just living in a json file in this repo 🤔

[dsanders11]

These dates shouldn't need to be hardcoded, they can be auto-generated from historical release data?

Fair point, I could look at making that change and generating them from the releases data.

Unless the intention is that these are date predictions, in which case I'm not a huge fan of this just living in a json file in this repo 🤔

For future versions (like 26 in this case) the alpha/beta/stable dates are added to e/e as date "predictions" (AKA the schedule) via PRs like electron/electron#38378.

The point of them "just living in a json file in this repo" is they need to live somewhere (currently in that table in e/e docs), and if they live here they can be used to generate that table in the docs instead, in addition to being generally available in machine-readable form for usage in automation.

One of the current main motivators of this PR is for the dates for the next release branch to be available in machine-readable form for the new release board automation on e/e so it can fill in dates for when specific items need to be done by.

[dsanders11]

Idea which came up in the @~electron/wg-releases meeting today - what if alpha/beta/stable is auto-generated from historical data if those releases for that major have already happened (ignoring any hardcoded values) and uses the hardcoded "predictions" otherwise? Then as part of updating the scheduled dates for the next major version the PR would just cull the old dates for released versions (except for EOL).

in which case I'm not a huge fan of this just living in a json file in this repo 🤔

If this is the biggest concern, is there a spot you'd rather have it? I agree I'm not a huge fan of it being in this repo, but since this repo serves /releases.json it seemed like the spot with the fewest moving pieces. If we'd rather we could put it somewhere in e/e and have it grabbed (and cached) via octokit?