Skip to content

API-change without SO-name bump… #654

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

Closed
besser82 opened this issue Aug 28, 2017 · 7 comments
Closed

API-change without SO-name bump… #654

besser82 opened this issue Aug 28, 2017 · 7 comments

Comments

@besser82
Copy link

besser82 commented Aug 28, 2017

8996c37 introduced an API / ABI change without correctly bumping the SO-name… This affects v1.8.2 release. Sadly it's not the first time this happens…

@cdunn2001
Copy link
Contributor

I was afraid of that. (See release notes.) We'll bump the ABI version number.

@besser82
Copy link
Author

Thank you! =)

@cinemast
Copy link
Contributor

@cdunn2001 Might I suggest the great tools of @lvc https://github.com/lvc/abi-tracker

@cinemast
Copy link
Contributor

https://abi-laboratory.pro/tracker/compat_report/jsoncpp/1.8.1/1.8.2/b37a5/abi_compat_report.html It did in fact catch the problem.

@cdunn2001
Copy link
Contributor

@besser82 and @cinemast, Sure, that's a good idea to check the abi-tracker for symbol changes in the future.

However, was there any actual problem this time. The abi-tracker shows only one removed symbol, Value::CZString::operator = ( Value::CZString other ), replaced by reference and move versions. CZString is private. Publicly, it is used only in ObjectValues* map_, which is a pointer that is not dereferenced publicly. I do not see how anything could have broken.

Just for clarification, are you saying that you prefer to trust the strict abi-checker? Or was there an actual runtime problem somewhere?

@besser82
Copy link
Author

@cdunn2001 In this particular case it possibly wouldn't have done any harm, but none the less the exported symbols of the dso were changed. In such cases it's always recommended to bump the dso version, just to play safe.

@besser82
Copy link
Author

@cdunn2001 Could you please tag the new release, so I can update to recent version in Fedora?

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

3 participants