node@14: deprecate on 2023-04-30 (EOL)

[cho-m]

Planning for upcoming node@14 EOL.

Checking for maintainer feedback on how we want to handle this, e.g.

• Option 1 (2023-04-30): Approach in PR where we deprecate node@14 on EOL to prevent new usage in homebrew-core and we start a removal time limit on dependents that are still using EOL node@14.

• Option 2 (2023-09-11): We can extend deprecation to at latest openssl@1.1 EOL (2023-09-11) and move date earlier upon any CVE. Based on other repositories, it looks like node@14 does not support OpenSSL 3. We probably do not want any non-deprecated formulae using OpenSSL 1.1 after EOL, so that date would be latest we could delay.

  • Arch: archlinux/svntogit-community@726f70f
  • Gentoo: https://gitweb.gentoo.org/repo/gentoo.git/tree/net-libs/nodejs/nodejs-14.21.2.ebuild#n43
  • NixOS: NixOS/nixpkgs@ed3fab5

---

As note, both balena-cli and opensearch-dashboards were stuck on EOL NodeJS (node@12 and node@10 respectively) for a while.

[p-linnane]

👍 for option 1

[ZhongRuoyu]

👍 for option 1, in line with upstream decision.

[Bo98]

I say option 1 (deprecate on 2023-04-30) with a full disable date of 2023-09-11.

[Bo98]

We'll need to discuss strategy regarding OpenSSL 1.1 soon (because of notice periods). We're usually quite strict with security formulae - we outright deleted OpenSSL 1.0 on its EOL date last time so we'll need to discuss when exactly when we deprecate and when we disable (3 months minimum between the two stages).

This in turn affects Node 16.

[chenrui333]

for option1 (life is easier 😅 )

[cho-m]

Removing do not merge based on feedback. May add a comment to upstream issues to notify of upcoming deprecation.

[BrewTestBot]

🤖 A scheduled task has triggered a merge.