Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please follow Semantic Versioning #91

Open
cbauer10 opened this issue Feb 7, 2023 · 2 comments
Open

Please follow Semantic Versioning #91

cbauer10 opened this issue Feb 7, 2023 · 2 comments

Comments

@cbauer10
Copy link

cbauer10 commented Feb 7, 2023

It would be really appreciated if semantic version was followed in this repo. Both 0.4.5 and 0.4.6 included breaking changes and it is cumbersome to have to manually update this library and keep track of what it is doing instead of consuming what should have been non breaking changes.

@hamchapman
Copy link
Collaborator

I understand the frustration in general and apologies for any issues that you've run into because of the nature of these releases.

I'd be curious as to what you were doing that made 0.4.6 a breaking change for you?

You may well already know this but strictly speaking semantic versioning specifies the following:

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

https://semver.org/#spec-item-4

@cbauer10
Copy link
Author

We are implementing the CBOREncodable Protocol so when a method is changed, like what happened in 0.4.5 and 0.4.6, our code is no longer able to compile.

Yes I realize the legal reason as to why you are keeping this at 0.x.x, but it would still be appreciated if some semblance of semantic versioning was followed to where incrementing the bug fix number is not a breaking change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants