Release candidate

[dyladan]

Is it sufficient to put on the README for the API that 0.18 is the release candidate? Or do we want to release something like 1.0.0-rc.1?

Originally posted by @dyladan in open-telemetry/opentelemetry-js#1982 (comment)

[dyladan]

/cc @open-telemetry/javascript-maintainers

[vmarchaud]

I think we can tag it both on github and npm ?

[dyladan]

I think we can tag it both on github and npm ?

To me it seems like there are a few places we could tag the current version as RC:

• GitHub README
• git tag (rc1 or similar?)
• npm release tags (rc maybe?). I'm not sure how useful this is because when people do npm install @opentelemetry/api, they will get latest by default so marking it as rc is unlikely to be seen or noticed by anyone.

In addition to that, we could release a version like 1.0.0-rc.1 which follows semver conventions for a prerelease.

The question is: is it sufficient to tag 0.18 as our release candidate? Or do we need to release a semver prerelease version also?

[vmarchaud]

looking at other SIGS:

• python made a release: https:/open-telemetry/opentelemetry-python/releases/tag/v1.0.0rc1
• java directly released 1.0: https:/open-telemetry/opentelemetry-java/blob/main/CHANGELOG.md#version-100---2021-02-26
• .net did few RCs: https:/open-telemetry/opentelemetry-dotnet/tags
• go hasn't made a RC yet

Do we actually expect to run RC release ? If not i'm not sure making a full release would be that useful. Generally i would go with git tag + npm releases to tag it somewhere.

[legendecas]

If we define such release as RC, I'd vote for semver like 1.0.0-rc.1 to explicitly say that this version is ready for a stable release. And people can start using ^1.0.0-rc.1 version range, which would get updated if we released stable 1.0.0.

[dyladan]

This is why I wanted it to be the same as 0.18. If someone installs npm i @opentelemetry/api they will get 0.18.0, but using npm tags we can make it so if they explicitly install npm i @opentelemetry/api@rc they can get 1.0.0-rc.1 which will automatically be updated to 1.0.0. This means we can "safely" add breaking changes to the RC if absolutely required because users have explicitly opted into it.

[vmarchaud]

I see, i think adding a note in the readme + a tag on github (that point to the same commit as 0.18.0) for historic purpose would be fine ?

[Flarna]

This means we can "safely" add breaking changes to the RC

As far as I remember your version check in API doesn't include the pre-release part. Therefore I think breaking changes are no longer allowed in this phase.

[dyladan]

This means we can "safely" add breaking changes to the RC

As far as I remember your version check in API doesn't include the pre-release part. Therefore I think breaking changes are no longer allowed in this phase.

That is correct. I didn't mean "safely" as in "it wont break users" but the only users who have the rc are ones who are explicitly opted in. I think we should try as hard as possible to avoid breaking.

[vmarchaud]

I believe we can close this since we went GA