Skip to content

Serve the Release/schedule.json file from the website #904

Open

Description

@bnb

Right now, my package nodevu relies on Release/schedule.json to enrich Node.js version data. This information - even if inaccurate or unreliable! - is very helpful at enriching dist/index.json into a more end-user friendly API.

I'd really love it if this information was available on the website directly, even if put in an experimental/untrusted/unreliable position (/dist/DONOTUSE/schedule.json, /untrustworthy/schedule.json, etc.). In talking with @ovflowd, apparently nodejs.org's usage of nodevu does sometimes get rate limited by GitHub because it's hitting this file frequently enough.

I recall that in the past @nodejs/release has been hesitant to provide a contract for this file. I'd be 100% okay with taking on the maintenance burden of having breaking changes be unannounced and fully reliant on consumers with no commitment from @nodejs/release. Having it on the website would just be really nice.

Activity

  1. aduh95 commented on Apr 14, 2026

    @aduh95
    Contributor

    @bnb can you describe what information you need from schedule.json? Assuming it's only a subset, maybe those could be added to index.json directly

  2. MattIPv4 commented on Apr 14, 2026

    @MattIPv4
    Member

    At least for the website itself, the only information we need from the release schedule is EOL dates, I believe. Everything else can already be inferred from dist/index.json? I'm not convinced we should expose the other information from the release schedule, as it creates a false understanding of Node.js releases, as the source of truth for things like LTS status is index.json?

  3. bnb commented on Apr 14, 2026

    @bnb
    Author

    nodevu uses all of the information from schedule.json 😅

  4. flakey5 commented on Apr 15, 2026

    @flakey5
    Member

    I'm not convinced we should expose the other information from the release schedule, as it creates a false understanding of Node.js releases, as the source of truth for things like LTS status is index.json?

    +1, I'm more in favor of adding that data into index.json

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions