Discussion: Drop support for older Node.JS versions

[rauno56]

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.

• This only affects the JavaScript OpenTelemetry library

[rauno56]

My proposal

• drop support for 8 and 10.
• remove the tests, builds, and compatibility layers(if we have any) for those versions.
• establish 6 month grace period for dropping support for EOLed node versions.

Arguments:

• OTel JS is a relatively young project - less legacy deployments, node@8 was already EOL when the first version of @opentelemetry/api available on npm was released(0.4.0),
• node versions upgrade quite well,
• There's no significant split in terms of users staying on old versions(re: python),
• There are no widely shared reasons not to upgrade afaik.

[legendecas]

+1. It sounds good on 6 month period for dropping support for EOL node versions.

[legendecas]

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.

[habmic]

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.

[vmarchaud]

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 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

[rauno56]

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?

[dyladan]

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.

[rauno56]

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.

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."

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)

[dyladan]

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).

[vmarchaud]

There is nothing in the versioning doc that states if major version releases are allowed in the SDK

I don't think we count instrumentations as part of the SDKs ? Or maybe core ones ?

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.

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.

[rauno56]

Talked about this in the SIG meeting and concluded:

1. Contrib will continue dropping support for versions it's not able to realistically maintain(for example if newer versions of the lib do not support old versions of node). This will be fine for now, but can cause us problems down the line. We'll cross that bridge then.
2. Core/SDK will be more restrictive and will try to support versions as old as it can to widen the supported usage scenarios. If we do need to drop support, we should probably do what every other npm package does and bump the major.
3. API should not drop support until we get an confirmation/guidance from spec for that.

• Update docs on core and API to communicate support from until 8.12.0 and above(because of the case @svetlanabrennan reported in Incorrect span timestamp for node version 8.11.4 to 8.10.0 #2834),
• Update docs on contrib to communicate more freeflowing nature of the supported node versions.
• Talk to spec about versioning. @dyladan, could you find time for that?

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.

[dyladan]

• @dyladan, could you find time for that?

Yes I'll reach out to ted

[rauno56]

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.

[dyladan]

Update docs on core and API to communicate support from until 8.12.0 and above(because of the case @svetlanabrennan reported in #2834),

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

[dyladan]

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

[dyladan]

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

[smith]

For reference:

• Node releases
• AWS Lambda runtime support policy

[dyladan]

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

[legendecas]

Does this still need to be worked on after #3048 has landed?

[dyladan]

No