Package-maintenance: Standard grammar/keywords to reference node release lines

[dominykas]

Background:

• The support levels doc has a support target field, which references the node version support policy that the package aims to provide (as well as several "unsupported" options)
• As discussed in #205, CI systems would ideally be able to define the list of node versions to test in as a single policy keyword
• Renovate provides a way to configure the support policy for automatically updating node version reference files (engines in package.json, .travis.yml matrix, .nvmrc)

Not sure if it is in scope for this group to standardize such a grammar or whether this discussion should be moved elsewhere, but renovate's grammar is a reasonable starting point *, so at the very least we might want to discuss if we should adopt it for the support-target field **:

| supportPolicy | versions | description |
| ------------- | ---------- | -------------------------------------------------------- |
| all | 8,10,11,12 | All releases that have not passed their end date |
| lts | 8,10 | All releases classified as LTS, including in maintenance |
| active | 10,12 | All releases not in maintenance |
| lts_active | 10 | All releases both LTS and active |
| lts_latest | 10 | The latest LTS release |
| current | 12 | The latest release from "all" |

(source)

I believe lts_latest in renovate's dictionary is equivalent to lts/* in nvm, but it does need (as well as nvm) a way to specify "oldest supported LTS" (and similar).

I'm also aware some people like to test/support down to minor and even patch level of node, but I'm not sure there's a need for a grammar to reference them.

As much as I'm reluctant to go provider specific, there is also the case of AWS Lambda, which is usually several minor version behind latest, so this might be useful to include in the keyword list (at the cost of simplicity...)

---

• * - I have to admit that I do think that current language used in terms of "active" vs "lts" vs "maintenance lts" releases is rather complex and has mislead people in the past, but at this point I do not have concrete suggestions on how to improve it... And that's probably outside of scope of this group anyways.
• ** - I wonder how would this transfer to other ecosystems and whether we should aim for a more abstract support-target field, which is closer to a dictionary a la engines in package.json.

[ljharb]

The only ecosystem I really think we need to concern ourselves with is node's - which will always have a package.json or equivalent.

[BethGriggs]

We've been discussing something similar over in https://github.com/nodejs/Release/issues/359

[mhdawson]

I'm always in favor of starting with something in use as opposed to re-inventing the wheel unless we have reasons that mean what's in use is not a good fit. I'd be in favor of starting with it and then adding:

• abandoned
• none

[Eomm]

Update the #220 with this mapping:

abandoned -> added 🆕
none -> added 🆕
all -> was superset
lts -> was lts
active -> added 🆕
lts_active -> added 🆕
lts_latest -> was latest
current -> added 🆕

How we could call also those packages that support EOL node? all_eol?

I will follow the issue by the release WG to update the PR accordingly

[ljharb]

just “all”? but also, i don’t think that’s really the case for anyone; none of my packages, even, support node < 0.4 :-)

[mhdawson]

I think just "all" makes sense to me as well. Since active should cover all that are not EOL.

[mhdawson]

Scratch my last comment as "active" is something different in what we have.

[mhdawson]

Next action was for @BethGriggs to get us some feedback from the Release team

[Eomm]

Watched the meeting from 22:00

we should mainly:

• clarify the difference between all and maintained
• lts_active could have 6 months overlap

The nice idea is to see those tags in the download page of the site

[mhdawson]

@Eomm do you want to submit a PR do the doc to address those 2 comments or would you like me to?

[Eomm]

I will open it 💪

[mhdawson]

Michael also needs to do PR for this: https://github.com/nodejs/Release/issues/359

[wesleytodd]

So I wrote this the other night: ~https://github.com/wesleytodd/node-matrix/blob/master~/versions.js~

EDIT: I moved the implementation to a module. https://github.com/pkgjs/nv

It implements the aliases discussed here (and in the support doc) and will return the current node versions for the given aliases. The repo it is in was me experimenting with an action which would automagically update a test matrix. The same approach could apply to a travis config. I was wondering if this seemed like a good and long term viable approach to improving the situation here.

Note: it doesn't work yet because of a bug in github actions which prevents personal access tokens from pushing workflow changes: https://twitter.com/chrisrpatterson/status/1176851927918948352

[bnb]

Heh, I came to this issue to ask if the Package Maintenance WG would be willing to maintain a module for this – regardless of whether the output is static JSON (something like node-releases or if it was actually a dynamic resolution tool (or both).

I would really love to see us pull in @pkgjs/nv or some variant as a Package Maintenance WG supported module.

[wesleytodd]

I would really love to see us pull in @pkgjs/nv or some variant as a Package Maintenance WG supported module.

As I have proposed before, I am super happy to have that Org be a place to collaborate. Anyone who wants in just has to ask!

And also, I plan on supporting that specific package indefinitely, so you might consider it "WG supported" as I also plan on being a part of this WG indefinitely. Please don't kick me out 📦 😛

This brings up an interesting point I made here. How do we want to "support" modules for our initiatives?

If we move them into the node org there is some level of "blessed implementation", which has both pro's and con's. As @Eomm points out, we might be able to move faster with less eyes than we would get working inside the node org.

a faster create-publish-fail, create-publish-fail, create-publish-success that maybe we can't do in the nodejs org

[mhdawson]

Waiting on PR for release, node core and website to make sure we have the consistent language - Michael has action, but has not done it yet.

[mhdawson]

I looked through the doc in the Release WG repo (https://github.com/nodejs/release) I did not find anything I thought needed to be updated.

Will look at main Node.js repo next.

[mhdawson]

I looked through the docs in the main repo. I did not find anything that I through needed an update to be consistent with the grammar we've defined.

Closing