-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: support node v14 #7582
feat: support node v14 #7582
Conversation
I think so, because we sometimes depend on features which are added to the major releases prior to LTS, and we have no interest in chasing after pre-LTS versions to work out why something's failing. |
This comment has been minimized.
This comment has been minimized.
should we skip v12 or v14 tests on windows? as we've done with v10 before? |
Does this require a major version bump? |
Why? because we do not support node v13 anymore? |
i can split this pr, so we first enable testing v14 only and later change the package.json node requirementes with a major bump, maybe dropping node support <14.15.0 |
Yeah, it's technically breaking. Though now that I think about it, we drop unsupported versions of GHE without making a major release. This probably falls in the same category. |
I don't see why it's a major for us to add v14 support, although if we're taking anything away and it's deserving of a major then we could wait and combine it with others if it's not too inconvenient. |
so yes, i think it's ok to drop unsupported versions with a minor update
It's not because adding v14 support, it's because we explicit disallow node |
🎉 This PR is included in version 23.65.0 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
::set-env
deprecationshould we be more strict, eg
^12.13.0 || >=14.15.0
, as14.15.0
is first v14 lts ?