Adopting semantic versioning

[inverse]

First up thanks for providing this awesome library for folks to to leverage JWT in their applications.

I noticed that this project doesn't follow semantic versioning schema for new releases, which is a common versioning schema to help consumers understand better when breaking changes are introduced.

e.g. going from 2.8.2 -> 2.9.0 removed the JWT::JWA.create function which was replaced with JWT::JWA.resolve

Would this be something your project would consider adopting?

[anakinj]

Thanks for pointing this out. We try to be as backwards compatible as possible and try to obey the documented behaviour. The challenge comes with the interfaces that is intended to be internal as the one you pointed out. As there are no ways to prevent the use of internals its a bit challenging to keept track of them. To preserve compatibility for all interfaces and classes in the gem would be a nightmare.

[anakinj]

Im going to close this one as we try our best to follow sematic versioning to the documented public apis. If there are some suggestion on how to be better at communicating what are internal interfaces and what public. Please shout out...

[inverse]

yeah not sure how Ruby handles keeping internals private but I guess having some e2e tests that cover the public API could ensure that the desired public aspects are kept semantic. But it's fine to have this ticket closed

[anakinj]

Currently pretty eager on the closing-finger and I realized that I was about to ask was that if the functionality the JWT::JWA module provides would be useful to document and support officially. That would also be an option to actually have a public API for that one.

Guess bringing this up was some functionality actually breaking...