Closed uberDoward closed 2 months ago
Current documentation is
Although neither of those would appear to state what your internal team is after.
I have been unsuccessful in communicating this to our internal End of Life team, and they require official documentation from the vendor before they will let me mark a minor version deprecated and no longer permitted for use.
"no longer permitted for use" is not something that Node.js would state[1] -- that would be a decision for your internal processes/team. You are free to use whatever version of Node.js you like, but if you want to report an issue the Node.js project is likely to ignore it unless it is reproducible on a supported release line. You would also be likely asked if the problem reproduces on the latest version within that release line (e.g. check if the problem hasn't already been fixed).
[1]: even for End-of-Life releases. You're encouraged to use supported versions of Node.js, and if running something important (in "production") you are encouraged to use a Long Term Support release line.
I am also not at all opposed to writing up this document myself and submitting a PR - just let me know how the Node TSC would like this to proceed.
I'd encourage you to do just that. Things tend to get resolved quicker in pull requests than discussed in meetings/issues.
I have to get approval before I may submit the PR.
To be clear, "no longer permitted for use" is not what I would like Node to state, lol.
I would be aiming for something like "A new minor release supersedes and deprecates the prior minor release for a given major version (eg, 20.5's release means 20.4 will no longer be actively* supported)".
Would this be acceptable?
I would not use the word "deprecates". Maybe something like "A new release within a release line supersedes previous releases on that line. Any fixes on the release line will be released as the next semver minor or semver patch release from the most recent release on that line."
cc @nodejs/releasers
I would not use the word "deprecates". Maybe something like "A new release within a release line supersedes previous releases on that line. Any fixes on the release line will be released as the next semver minor or semver patch release from the most recent release on that line."
cc @nodejs/releasers
That still accomplishes my goal of providing appropriate expectations of version life within minor versions. I'd be perfectly happy with that verbiage.
It seems there has been no activity on this issue for a while, and it is being closed in 30 days. If you believe this issue should remain open, please leave a comment. If you need further assistance or have questions, you can also search for similar issues on Stack Overflow. Make sure to look at the README file for the most updated links.
It seems there has been no activity on this issue for a while, and it is being closed. If you believe this issue should remain open, please leave a comment. If you need further assistance or have questions, you can also search for similar issues on Stack Overflow. Make sure to look at the README file for the most updated links.
Details
Let me first preface this with an apology. I, like every other developer on the planet, am well aware that when Node 20.3 is released, that very implicitly makes 20.2 deprecated.
I have been unsuccessful in communicating this to our internal End of Life team, and they require official documentation from the vendor before they will let me mark a minor version deprecated and no longer permitted for use.
If anyone on the Steering Committee could perhaps point me to a document that spells out the obvious, I would be grateful.
I am also not at all opposed to writing up this document myself and submitting a PR - just let me know how the Node TSC would like this to proceed.
Node.js version
Not applicable.
Example code
No response
Operating system
Irrelevant
Scope
Documentation
Module and version
Not applicable.