RFC 710: Formalizing a Node Deprecation Strategy for AWS CDK

[adamjkeller]

This is a request for comments about formalizing a deprecation strategy for Node.js in the AWS CDK. See #710 for
additional details.

Rendered Version

---

By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache-2.0 license

[johnf]

A couple of thoughts

Is there a good reason to support non-LTS versions? No one should be using these in production. It would halve the number of releases that need support and move the deprecation cycle to yearly.

I recommend aligning with Node.js's EOL. Node.js provides 30 months, which is effectively 2 years plus 6 months.
By aligning, we discourage users from running unsupported versions of Node in production. Deprecation notices can be sent two years out, which still gives a six-month warning. If a deprecation policy exists, then users immediately have notice of when support will end, so we shouldn't need to give them extra time.

It could be handy to link to https://endoflife.date/nodejs or https://nodejs.org/en/about/previous-releases as a reference.

[jiayiwang7]

Is there a good reason to support non-LTS versions?

You're right that most production users should be on LTS releases. Our primary focus is indeed on LTS versions, though we've found some developers use non-LTS versions in development environments or for testing new features. Supporting those non-LTS versions can be important for those targeted use cases.

I recommend aligning with Node.js's EOL. Node.js provides 30 months, which is effectively 2 years plus 6 months.

The reason we plan to maintain the EOL + 6 months approach as originally proposed is because it aligns with the support model used by other AWS services, including the AWS SDK for JavaScript, which follows a similar EOL + 6 months pattern (as referenced in the RFC). This consistency across AWS developer tools provides a more predictable experience for our users.

The 6-month grace period serves several purposes:

1. It gives enterprise customers additional time to complete their upgrade cycles
2. It maintains consistency with other AWS developer tools
3. It provides a balanced approach between security and practical migration timelines

It could be handy to link to https://endoflife.date/nodejs or https://nodejs.org/en/about/previous-releases as a reference.

Appreciate the suggestion. We'll definitely include these references in our future version documentation page to help users track upcoming EOL dates.