Repository navigation
Standard grammar/keywords to reference node release lines #236
Description
Background:
- The support levels doc has a support
targetfield, which references the node version support policy that the package aims to provide (as well as several "unsupported" options) - As discussed in Reach out to Travis to get option that includes #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 (
enginesinpackage.json,.travis.ymlmatrix,.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 abstractsupport-targetfield, which is closer to a dictionary a laenginesinpackage.json.
Activity
ljharb commentedon Jul 30, 2019
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 commentedon Jul 30, 2019
We've been discussing something similar over in nodejs/Release#359
mhdawson commentedon Jul 30, 2019
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:
Eomm commentedon Aug 16, 2019
Update the #220 with this mapping:
abandoned-> added 🆕none-> added 🆕all-> wassupersetlts-> wasltsactive-> added 🆕lts_active-> added 🆕lts_latest-> waslatestcurrent-> 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 commentedon Aug 16, 2019
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 commentedon Aug 16, 2019
I think just "all" makes sense to me as well. Since active should cover all that are not EOL.
mhdawson commentedon Aug 16, 2019
Scratch my last comment as "active" is something different in what we have.
mhdawson commentedon Aug 27, 2019
Next action was for @BethGriggs to get us some feedback from the Release team
Eomm commentedon Aug 31, 2019
Watched the meeting from 22:00
we should mainly:
allandmaintainedThe nice idea is to see those tags in the download page of the site
mhdawson commentedon Sep 5, 2019
@Eomm do you want to submit a PR do the doc to address those 2 comments or would you like me to?
Eomm commentedon Sep 7, 2019
I will open it 💪
mhdawson commentedon Sep 24, 2019
Michael also needs to do PR for this: nodejs/Release#359
wesleytodd commentedon Sep 25, 2019
So I wrote this the other night:
https://github.com/wesleytodd/node-matrix/blob/master~/versions.jsEDIT: 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 commentedon Sep 30, 2019
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/nvor some variant as a Package Maintenance WG supported module.wesleytodd commentedon Sep 30, 2019
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.
mhdawson commentedon Nov 5, 2019
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 commentedon Nov 28, 2019
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 commentedon Nov 28, 2019
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