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

add versioning to shared libs #2516

Merged
merged 2 commits into from Oct 4, 2022
Merged

add versioning to shared libs #2516

merged 2 commits into from Oct 4, 2022

Conversation

jonathanspw
Copy link
Contributor

I'm not sure what you have planned for ABI/API compatibility so versioning it to major.minor might be more appropriate than just major.

@codecov
Copy link

codecov bot commented Sep 8, 2022

Codecov Report

Merging #2516 (6b690a6) into devel (32eae0e) will not change coverage.
The diff coverage is n/a.

❗ Current head 6b690a6 differs from pull request most recent head 18271b0. Consider uploading reports for the commit 18271b0 to get more accurate results

@@           Coverage Diff           @@
##            devel    #2516   +/-   ##
=======================================
  Coverage   91.54%   91.54%           
=======================================
  Files         183      183           
  Lines        7561     7561           
=======================================
  Hits         6921     6921           
  Misses        640      640           

@horenmar
Copy link
Member

horenmar commented Sep 9, 2022

ABI stability: NOPE
API stability: semver (modulo bugs and Hyrum's law)

@dimztimz
Copy link
Contributor

Becauase there is no ABI stability whatsoever, SOVERSION should contain all three parts of the version i.e. SOVERSION should be the same with PROJECT_VERSION.

@jonathanspw
Copy link
Contributor Author

So even minor versions will potentially change ABI?

That's pretty contradictory to how most ABI versioning works. Can ABI stability be maintained within X.X releases so that x.x.X can be considered bugfix only, or at least non-breaking?

@horenmar
Copy link
Member

So even minor versions will potentially change ABI?

Yes. Catch2 is meant to be used as a static library. As such, it should not be installed globally and ABI stability is a non-concern.

For various reasons, we also support building it as a dynamic library, but there is a number of limitations to it, e.g. symbols are exported only implicitly. Providing ABI stability is a maintenance cost I am not willing to pay.

@horenmar horenmar added the Building and Packaging Issues affecting build/packaging scripts and utilities label Sep 16, 2022
src/CMakeLists.txt Outdated Show resolved Hide resolved
src/CMakeLists.txt Outdated Show resolved Hide resolved
@horenmar horenmar merged commit 0e139b7 into catchorg:devel Oct 4, 2022
@jonathanspw jonathanspw deleted the patch-1 branch October 4, 2022 14:02
@jonathanspw
Copy link
Contributor Author

Thanks for the tweaks and getting this merged!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Building and Packaging Issues affecting build/packaging scripts and utilities
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants