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 revert 1ce3db3c or make a new major release #46

Open
clausecker opened this issue Jan 18, 2016 · 6 comments
Open

Please revert 1ce3db3c or make a new major release #46

clausecker opened this issue Jan 18, 2016 · 6 comments
Milestone

Comments

@clausecker
Copy link
Collaborator

The commit 1ce3db3 completely breaks the libfreefare API. This is a bad thing. Please either revert it or make a new major release to underline that the new version has a completely incompatible API.

@smortex
Copy link
Contributor

smortex commented Jan 18, 2016

HI,

While it is not stated anywhere, me follow the Semantic Versioning Specification. Quoting it:

4 - Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

The referenced commit renames enum values. If you do not want to synchronize your code (yet), I invite you to add some #defines to map the old names onto the new ones during the transition.

@smortex smortex closed this as completed Jan 18, 2016
@clausecker
Copy link
Collaborator Author

It has been like this for three years now without any indication that the software is still actively changing, at least not in any project documentation I found. No, not releasing a 1.0.0 version is not a magical ritual that deflects the responsibility for API stability from you. You are doing all your users a huge disservice by breaking the API like this. I'm seriously considering a fork at this point just so I don't have to fix my go bindings (which have been stable for two years now) every time you decide to break the API.

@smortex smortex added this to the 1.0.0 milestone Jan 18, 2016
@smortex
Copy link
Contributor

smortex commented Jan 18, 2016

I understand your point, I'm adding this issue to the 1.0.0 milestone

@smortex smortex reopened this Jan 18, 2016
@smortex
Copy link
Contributor

smortex commented Jan 18, 2016

As a consumer of the library, you may also have interesting insights about it. Feel free to open issues or submit pull requests and assign them to the 1.0.0 release ;-)

@clausecker
Copy link
Collaborator Author

If you are going to break the API anyway, consider removing all uses of pragma pack from the public interface. Pragma pack makes it very hard to use your library from other languages as not all foreign function interfaces support the non-standard pragma pack. There isn't a good reason why it's there either.

@clausecker
Copy link
Collaborator Author

It seems like 42b21ff already broke the compatibility.

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