Release metadata

[rarkins]

Apart from the release.json in this repository, what other sources of node metadata can be considered authoritative? e.g. are node releases on GitHub the source for - or always in-sync with - what's published to nodejs.org?

In particular, I'm looking for metadata that will tell me:

(1) Which was the initial version for each LTS release (e.g. 8.9.0 for 8.x)
(2) Which is the "minimum recommended" version for each release for security reasons (e.g. 6.11.1 for 6.x)

Update: I have also found https://nodejs.org/dist/index.json which includes a list of all versions + a flag for LTS yes/no. This can be used to derive the initial version for each LTS.

[mhdawson]

@rarkins from your update it just sounds like you are missing (2) the minimum recommended base on security reasons, right ?

[rarkins]

@mhdawson yes, that's the case. Although if both (1) and (2) could be added to release.json in this repository, that would be far superior. Assuming that updating to/past important security updates is important for node users, putting it in the most obvious/easy location possible for automated flagging would be best.

[mhdawson]

@rvagg from the name schedule.json I'm guessing the intent was not to have data beyond the schedule but I can see the value of adding the requested data. 1) would be a one time thing, 2) would be a bit more work in that it would have to be updated for every security release.

[rvagg]

This is information that I'd like to have available as well. I don't mind extending schedule.json with this but the manual updating would be a problem. We'd just have to build that into doc/releases.md and scold people every time it's not done I suppose. The only other place I can imagine pulling it from is the commit log and/or blog post where we generally say "security" in there but there's no fixed format or even really a convention there, so it's going to have to be manual anyway I think.

[mhdawson]

@rvagg sounds good. I'll submit a PR for the changes to doc/releases.md

[bnb]

This may be something @nodejs/automation may be interested in helping out with. Seems like something that we may be able to automate and make seemless 😁

[joyeecheung]

I was not aware of schedule.json before this issue, but I can see where I could help. Off the top of my head, the approach that makes the most sense to me is first creating a tool that gives you a checklist for the release process (it can visit various urls and pattern match things in https://github.com/nodejs/node/blob/master/doc/releases.md). From there we could make the tool automate/generate templates for steps that should be relatively easy to automate, like nodejs/automation#14 (I am not a CLI guru, but I've seen some pretty powerful scaffolding Node.js CLI that do similar things interactivly)

(BTW, I couldn't find a reference to https://github.com/nodejs/node/blob/master/doc/releases.md in this repo, should we add one to the README?)

[iamstarkov]

@rarkins you might be interested in this https://github.com/chicoxyzzy/node-releases/

[chicoxyzzy]

Hi. I'm maintainer of node-release. I didn't implement any automatic generation of metadata yet because lack of time. It'd be great to have official automatically generated npm package which will be updated on each Node release. node-releases package is Browserslist's dependancy which we use in Babel's babel-preset-env. Let me know if I can help somehow!

[BridgeAR]

I added this to the next release agenda to discuss this at our next meeting.

[richardlau]

We added a security property to dist/index.json which can be used to work out (2) in a similar manner that the lts property can be used to work out (1). Is there anything further that needs to be done?

[BethGriggs]

@richardlau, I don't believe so. @rarkins please let us know if you disagree and I'll reopen the issue.

[bnb]

+1 to this being resolved.