@danschultzer can you please confirm you have thoroughly reviewed the Messaging Specification for any new or changed attributes that are applicable as well as any other sections? As far as I can tell this was not performed since nothing has changed in the setup for opting into experimental attirbutes which is essentially the entire messaging specification. Please refer to bandit, phoenix, cowboy, etc to familiarize yourself with the expected API.

It is not sufficient to just bump the dependency.

Thanks

Yes, it's all in the followup PR #436, which adheres as much as possible to 1.27 specs for messaging.

But it'll introduce many breaking change.

This PR only focuses on updating the dependency, but all the attributes are backwards compatible so I don't think it's necessary to force the changes here?

FWIW the dependency was not locked to 0.2, but allowed the range >= 0.2 and < 1.0, and most of the current libraries allows >= 1.27 and < 2.0.

Also one thing on all my PRs, I can update the changelog if it's preferred to do in the PR's. I'm not sure how the releases are managed.

Right, 1.27 does introduce a lot of breaking changes which is why we want it done properly and not just publishing a version with an updated dep with no actual updates. By going to 1.27 we are saying it is 100% 1.27 compliant to our knowledge. That's why this is a difficult update and folks have to exercise some patience. It's the most difficult update we'll have to make and hopefully the last for a long time.

I see, but then do we need to fixate the semantic conventions version to 1.27? Because it's at 1.29 now with more breaking changes, so whenever the semconv library gets updated we end up in the same place with drift if we continue using the ~> version requirement.

I was thinking of using this PR in a minor release to bump the semconv version (we could make the version here be ~> 0.2 or ~> 1.27 to really make it backwards compatible), and have a major release where all the breaking changes are included to conform it to 1.27 guidelines.

It gets the current dependency conflict out of the way without also breaking everything for the end-user (but they will get deprecation warnings which I think is ok).