You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Communicating that only the latest version of a major release line is supported #393
When people say they support e.g. Node 14.x, the usually (is that true?) mean that they only support the latest version in the 14.x line. At this time neither semver, nor PACKAGE-SUPPORT allows to define that as such?
Should we clarify that in the PACKAGE-SUPPORT doc?
Ideally, one would be able to communicate that via engines as well, but moving the semver standard might be trickier (if possible at all).
In the PACKAGE_SUPPORT.md I think the assumption (at least for me) is that the maintainer has said lts, 'active`, etc if you need updates they will only come in the next minor or patch release for the lines that they relate to.
So for example if you've chosen lts_latest and the latest LTS is currently 12.x that means effectively that if you have any problems in anything other than the latest 12.x release you'll have to upgrade to the latest.
But I guess that is different than which versions the package itself will work with and it is possible that a package might only work for a subset of the 12.x versions. In that case though you could use the engines so say it only runs on 12.5 or later.
It is an interesting question. If a module consumes a SemVer patch release of Node.js that forces users to update their Node.js version if they consume corresponding SemVer Patch version of the module.
I guess the question is if there needs some way for maintainers to say for a given LTS release line I won't use any of the SemVer minor features so you won't have to update Node.js when accepting SemVer minor/patch versions of the module. That actually sounds useful for end users, but I'm not sure I've seen that being done, except possibly in cases where people like @ljharb tries to support as far back as he can.
Activity
mhdawson commentedon Jul 30, 2020
In the PACKAGE_SUPPORT.md I think the assumption (at least for me) is that the maintainer has said
lts, 'active`, etc if you need updates they will only come in the next minor or patch release for the lines that they relate to.So for example if you've chosen
lts_latestand the latest LTS is currently 12.x that means effectively that if you have any problems in anything other than the latest 12.x release you'll have to upgrade to the latest.But I guess that is different than which versions the package itself will work with and it is possible that a package might only work for a subset of the 12.x versions. In that case though you could use the engines so say it only runs on 12.5 or later.
It is an interesting question. If a module consumes a SemVer patch release of Node.js that forces users to update their Node.js version if they consume corresponding SemVer Patch version of the module.
I guess the question is if there needs some way for maintainers to say for a given LTS release line I won't use any of the SemVer minor features so you won't have to update Node.js when accepting SemVer minor/patch versions of the module. That actually sounds useful for end users, but I'm not sure I've seen that being done, except possibly in cases where people like @ljharb tries to support as far back as he can.
ljharb commentedon Jul 31, 2020
Explicitly in semver tho, 14.x means any 14, including 14.0.0. There is no way in semver or npm to specify the latest minor on a major dynamically.
ghinks commentedon Aug 4, 2020
Unfortunately I too have always interpreted 14.x by the semver definition as above. Is it a common interpretation to think of this as latest?
lholmquist commentedon Aug 4, 2020
i assumed the same thing as well. I think of 14.x to be all of 14
dominykas commentedon Aug 4, 2020
Adding to next meeting agenda, let's talk this over.
dominykas commentedon Aug 25, 2020
Actions for @dominykas:
ci-config-travisto explicitly explain thisdominykas commentedon Aug 31, 2020
Included a note about this issue in nodejs/ci-config-travis#12.