Downstream packages cannot resolve latest cbor version due to non-semantic versioning of cbor

[ThisIsMissEm]

In the cose gem, they depended on cbor ~> 0.5.9 which doesn't seem to resolve correctly to 0.5.9.8 since ~> is a semantic version comparator, and this project isn't using semantic versioning.

It may be an idea to adopt semantic versioning which seems to be what rubygems recommends: https://guides.rubygems.org/patterns/#semantic-versioning (in their words "urges developers"), since this would avoid issues like this for cbor and other downstream dependents.

[cabo]

Can you describe the problem some more?

cbor ~> 0.5.9 works for me in some basic test:

$ irb
>> gem 'cbor', '~> 0.5.9'
=> true
>> Gem.loaded_specs["cbor"].version
=> Gem::Version.new("0.5.9.8")
>>

Please note also that in semantic version, major version 0 has special rules: https://semver.org/#spec-item-4

All that said, I'm not at all adverse to cleaning up the versioning of this gem; I'd just like to understand the specific problem first.

[ThisIsMissEm]

It may be that Mastodon's Gemfile.lock has pinned 0.5.9.6 when wanting ~> 0.5.9, even though a 0 major does mean anything can break & API is unstable, the version number must still conform to semver, which 0.5.9.6 does not, so I think that's probably breaking something in tooling causing a pinned version that cannot be upgraded without manually editing the lockfile

[cabo]

I don't have a lot of information to act on now. Can you show me a way to reproduce the problem?

[cabo]

Mastodon's Gemfile.lock has cbor (0.5.9.8).
After some more searching, I find an outdated Gemfile.lock at webauthn-ruby/spec/conformance/Gemfile.lock that has a cbor (0.5.9.6).
This has other, er, gems such as RUBY VERSION ruby 2.7.0p-1, so I think this just hasn't been touched in a while and needs to be updated.