Support Policy review

[shadowspawn]

I am taking a deep dive into our support policy and how it is communicated. This is prompted by sponsorship from the HeroDevs Sustainability Fund, and the guidelines there: https://www.herodevs.com/sustainability-fund

Another great source of guidance I found is from the maintainers of https://endoflife.date, who have the experience of finding or guessing the EOL information from many and varied products: https://endoflife.date/recommendations

Not many npm packages maintained by small teams have explicit support or EOL information. Common practice is that only the major version receives updates.

Commander is a widely used package. We do not maintain multiple release streams, and rarely backport changes, so support for older versions is somewhat theoretical. I would like to allow users time to transition to the current version after a major upgrade, while limiting our potential maintenance burden of old versions.

The support policy is currently included on security policy page. Our first documented policy was current major and previous major (#1004). To address short and unpredictable support period if we had close major releases, this changed to six months support for past version (#1114). To make it easy to understand and fit in with automated Tidelift patterns, and with our releases moving to a slower cadence, changed back to current major and previous major (#2150).

Ideas for improvements (WIP):

• the Security Policy page is primarily for reporting vulnerabilities (not documenting support policies)
• shift the support information to its own page, and link from support section in README
• mention follow semver on support page
• give idea of cadence for majors: about six monthly in recent years. Mention we do releases to drop EOL Node.js versions.
• perhaps hybrid policy: support period is current and previous major (simple), and earlier majors get total 12 months maintenance from when they left being current (so we can give dates and minimum time to migrate). Can use either rule alone to stay on a supported version.
• table with which version are current/security-only, and explicit date for EOL where possible