Formalize API release cadence

[dyladan]

We are currently preparing for the 1.1 release, but for features which did not make it into the release I believe we should have a more formal answer for when they may be expected to be released. I don't think we need anything very complicated or process-heavy, but I would suggest something like this:

• 1 minor release per month if there are new features ready
• 2 weeks before release, maintainers will look at open issues/PRs and determine which should be included in this month's release. Issues that are to be included will be added to the release milestone.
• Any features not added to the current release milestone should be added to the next release milestone by default unless an argument can be made to bring them forward or push them back.

[dyladan]

/cc @open-telemetry/javascript-maintainers

[blumamir]

I support

[dyladan]

I added the 1.1 and 1.2 milestones. Right now I added the PRs to 1.2 which are definitely not in 1.1 but they can always be pushed to 1.3 or later when we get to the release triage meeting. I set the due dates as the last wednesday of each month (1.1 this month, 1.2 next month).

[medikoo]

I have problems following a release process.

v1.1.0 is published, yet it's not marked as latest on npm (it's v1.0.4 that's latest). Is v1.1.0 considered as pre-release? If so why normal version (1.1.0) was it published under?

Which release is recommended to be used by users for stable environments? v1.1.0 or v1.0.4

[Flarna]

The API 1.1.0 is fine as is. But a version of sdk-trace-base supporting it is not yet released (it's an ongoing task).

So if you are only interested in the API and you don't use other OTel components (e.g. you implement your own SDK,...) it's fine to use 1.1.0. But if you intend to use the full set of OTel components (exporter, sdk,...) it's advised to stay on that ones tagged as latest at npm (and not deprecated).

One might think why a semver minor requires such a dependency. Well it's semver minor from API user point of view. But SDK implements the API therefore it should implement also the new parts added in the minor update to avoid problems that people use the new API but actually it doesn't work in an end to end setup.

[medikoo]

Currently semver contract seems broken. I had following setup in package.json:

    "@opentelemetry/api": "^1.1.0",
    "@opentelemetry/core": "^1.0.1",

And npm crashed on installation of that with:

npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR! 
npm ERR! While resolving: undefined@undefined
npm ERR! Found: @opentelemetry/api@1.1.0
npm ERR! node_modules/@opentelemetry/api
npm ERR!   @opentelemetry/api@"^1.1.0" from the root project
npm ERR! 
npm ERR! Could not resolve dependency:
npm ERR! peer @opentelemetry/api@">=1.0.0 <1.1.0" from @opentelemetry/core@1.0.1
npm ERR! node_modules/@opentelemetry/core
npm ERR!   @opentelemetry/core@"^1.0.1" from the root project
npm ERR! 
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.

Having that I needed to update the configuration into:

    "@opentelemetry/api": "~1.0.4",
    "@opentelemetry/core": "^1.0.1",

And that suggests that packages do not really follow semver here.

If things work with 1.0.4, they without a question should work with 1.1.0, while peer dependency setting on "@opentelemetry/core" states it's not the case.

[medikoo]

So question is, can we really use version ranges as "@opentelemetry/api": "^1.0.4", with open telemetry packages?

Or maybe we should assume it's not semver compliant and take each upgrade with caution?

[Flarna]

as said above it depends what you want. If you would like to combine various otel packages you have to take care to use versions which work together.
If you explicit select an api version which can't work with the core version you select it's by far better that npm tells this instead you end up in undefined behavior at runtime.