Define deprecation cycle for GAed components

[naseemkullah]

I think we should deprecate it and also aim to remove it from the distribution/repo.

Do we have a defined deprecation cycle for GAed components?

Currently there is a pinned dependency to core and sdk-trace-base which is problematic in case we just stop releasing new versions. Maybe exclude it from lerna project and change these deps to ranges and then stop releasing it?

Originally posted by @Flarna in #3585 (comment)

[dyladan]

Currently there is no official deprecation policy. In the past we've only deprecated 0.x components, never anything stable. The spec guideline is:

SDK stability, as defined above, will be maintained for a minimum of one year after the release of the next major SDK version.

Given that we wouldn't be releasing another major version, I would say it is probably fair to give it a deprecation notice and go 1 year from the setting of the deprecation notice or 1 year since the last minor release. I would remove the package from the lerna repo, replace it with a simple README deprecation notice containing instructions for using OTLP with jaeger, and publish security related bugfixes by branching from the last release if the requirement comes up. @open-telemetry/javascript-maintainers what would you think of a policy like that?

[Flarna]

I think besides the security fixes we have to ensure compatibility with API/SDK for this 1 year. I do not expect a lot changes in exporter related APIs therefore this should be not really an issue.

[legendecas]

I think besides the security fixes we have to ensure compatibility with API/SDK for this 1 year.

Does this suggest that we should keep the package in the lerna repo and testing it with the latest api/sdk? Which implies documentation deprecation.

[Flarna]

As far as I know keeping it in the lerna repo implies that dependencies are pinned and it's included in any release. I guess this is the easiest setup (because no change needed). But at least the final release should move to caret dependencies to allow to use it until they are really incompatible.

[dyladan]

We can change its package json to say private: true which should prevent it from being released again if we want to. i think the npm deprecation warning should be sufficient though

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.