Failed to resolve this package in environment where pre-releases are not allowed.

[prudnikov]

Describe your environment

OS: MacOS Python version: 3.11 SDK version: 1.27 API version: 1.27

What happened?

opentelemetry-semantic-conventions package is published with version like 0.48b0, which treated as BETA version. https://packaging.python.org/en/latest/discussions/versioning/

This package also is a peer dependency from apache-airflow.

As a result, opentelemetry-semantic-conventions package can't be resolved in the environments where pre-release packages are not allowed.

Steps to Reproduce

We use PDM.

pdm init

Add the following section to the pyproject.toml

[tool.pdm.resolution]
allow-prereleases = false

then run

pdm add opentelemetry-semantic-conventions==0.48b0

Expected Result

Package resolved and installed. This will work if package version will not include b0 suffix, so instead of 0.48b0 it should be 0.48.

Actual Result

❯ pdm add opentelemetry-semantic-conventions==0.48b0
Adding packages to default dependencies: opentelemetry-semantic-conventions==0.48b0
  0:00:00 🔒 Lock failed.  ERROR: Unable to find a resolution for opentelemetry-semantic-conventions
Please make sure the package name is correct.
  0:00:00 🔒 Lock failed.
See /Users/XXXX/Library/Logs/pdm/pdm-lock-58p93c2u.log for detailed debug log.
[ResolutionImpossible]: Unable to find a resolution
WARNING: Add '-v' to see the detailed traceback

Additional context

No response

Would you like to implement a fix?

None

[lzchen]

Given the decision to make incubating and stable namespaces for semantic conventions, we should theoretically not have anymore breaking changes going forward for the semconv package. Would it make sense to mark the package as stable?

It looks like Java has separate artifacts for stable and incubating.

@xrmx @aabmass thoughts?

[prudnikov]

Hello, team. Are there any updates on this?

[xrmx]

Given the decision to make incubating and stable namespaces for semantic conventions, we should theoretically not have anymore breaking changes going forward for the semconv package. Would it make sense to mark the package as stable?

It looks like Java has separate artifacts for stable and incubating.

@xrmx @aabmass thoughts?

I don't think beta or not makes a difference for semantic versioning when the version is < 1.0.0 right?

[prudnikov]

Given the decision to make incubating and stable namespaces for semantic conventions, we should theoretically not have anymore breaking changes going forward for the semconv package. Would it make sense to mark the package as stable? It looks like Java has separate artifacts for stable and incubating. @xrmx @aabmass thoughts?

I don't think beta or not makes a difference for semantic versioning when the version is < 1.0.0 right?

Not really. 0.1.0 is also release. It's <1.0.0 but it's not beta. Not everything <1.0.0 is beta. After BETA usually comes release. It can be <1.0.0 but it's release. And opentelemetry-semantic-conventions has only BETA releases.

Generally, <1.0.0 means that the API is not stable yet.

Also from SemVer docs

How do I know when to release 1.0.0? If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backwards compatibility, you should probably already be 1.0.0.

opentelemetry-sdk 1.26.0 depends on this. So according to Semantic Versioning this package should be >1.0.0. I have no direct dependency from opentelemetry-semantic-conventions, but it comes from apache-airflow which is also >1.0.0.

[prudnikov]

Hey team, sorry for bothering you again. Is there any updates/thoughts on this? https://peps.python.org/pep-0440/#handling-of-pre-releases

[aabmass]

Hey @prudnikov, we chatted about this. I think we are OK with removing the bx suffix for all our packages. We've had b0 as long as I can remember, but I don't think there's any downside to removing it for <1.x packages.

For opentelemetry-semantic-conventions specifically, it should be 1.x and we will follow up on that separate. But I think removing b0 should fix this issue.