-
Notifications
You must be signed in to change notification settings - Fork 821
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
Discussion: Drop support for older Node.JS versions #2721
Comments
My proposal
Arguments:
|
+1. It sounds good on 6 month period for dropping support for EOL node versions. |
While taking semver into consideration, should drop a node version support need a semver major or minor bump? If not, the applications that use a Node.js version (say v8.x) that goes out of grace period can be upgraded automatically to a version that is incompatible with the Node.js version (say v8.x) just dropped support, which can break the application. |
I did some research and found that NodeJS is publishing data about download per version (source: https://nodejs.org/metrics/summaries/version.csv) It seems like there is a lot of usage in the older version of NodeJS. (below is the usage of version 6 and above from January this year) I do agree that 6 months after EOL makes sense, but thought it would be interesting to check usage and share it. |
I know node itself drop support only with major bump and i think that make sense since it can break user apps. I don't think supporting ^8.5 like we do right now is a problem so i'm fine keeping this until we bump to 2.0 |
Yes, that would technically mean a major version bump. I don't think there's a reliable way to know how many people will be affected by this, unless vendors come forward and share usage statistics about their customer-base. Are major bumps something we want to avoid? Why? |
Just to avoid maintaining two parallel versions. The API and stability doc states "SDK stability, as defined above, will be maintained for a minimum of one year after the release of the next major SDK version." The API is specifically discouraged from major version bumps but the SDK doesn't seem to be. |
Technically we don't have to drop Node support in API. The issue is growing in contrib with having increasing number of issues because the instrumented libs do not even support node 10. CI is currently failing because of this. However, we can drop support for old node versions in problematic components - instrumentations are not stable yet and even if they were, we can get away with only bumping a version of an higher level component, not API or SDK.
Sure, but dropping the support has to come at some point, anyway. Postponing dropping the support only pushes the end of supporting two versions further into the future and makes it even more difficult during the tail end of that. Perhaps it's just not the best time because of the current state of priorities(metrics) and resources(not a lot) |
There is nothing in the versioning doc that states if major version releases are allowed in the SDK. It also doesn't specifically say a major version bump is needed to drop support for old runtimes (for example, the go SDK seems to only maintain compatibility for the previous 2 versions of go). |
I don't think we count instrumentations as part of the SDKs ? Or maybe core ones ?
We will have the issue either way, some instrumented libs might only support 16 right now and we will not be able to easily maintain them too. |
Talked about this in the SIG meeting and concluded:
Now technically changing support for node 8 version already means a major bump, right? Which, I guess, we will skip this time, but just shows the best-effort-stance on this. I personally just think supporting those has less benefit and more cost than what I've collected from the meetings. It is a tricky situation for sure. |
Yes I'll reach out to ted |
Talked about this in the SIG meeting again and the consensus between the people who did participate in the discussion was that the best balance is to drop support for any EOL node versions whenever we are making a major release. By the spec we are expected to support any old major versions for a year after the next major release has been cut(3 years for the API) so that covers the grace period. Relevant spec here. |
As pointed out by @Flarna in open-telemetry/opentelemetry-js-api#159 the API doesn't use perf hooks and does not have the bug which necessitated the bump to 8.12 and I think it can be left alone so we don't have to worry about if it is a breaking change or not for the API |
We discussed this in the SIG meeting again today. There is now a spec PR open which addresses this and would allow us to deprecate support for old runtimes without a major version bump in the SDK which I think we should take advantage of. This depends on open-telemetry/opentelemetry-specification#2510 |
We will also need to define an official policy for which versions to drop so that users can be sure of when they will be supported to on older runtime versions |
For reference: |
I would propose EOL + 1 year. This would mean dropping 8 and 10 now, and dropping 12 in april of next year. Will bring up in SIG |
Does this still need to be worked on after #3048 has landed? |
No |
During the SIG meeting(2022-01-12) we discussed the process of dropping support for older Node.JS versions.
For me, it makes sense for us to officially support all supported Node versions and remove running tests from the old versions with a grace period so that we also could keep up with the advancements of the ecosystem and tooling.
We currently support
>=8.5.0
>=8.12.0
.node@8
was released mid-2017 and EOLed on 2019-12-31.node@10
was released mid-2018 and EOLed on 2021-04-30.node@12
is currently in maintenance LTS and will be EOL on 2022-04-30.The text was updated successfully, but these errors were encountered: