Skip to content

[Breaking Change] CMake install target changed from cereal to cereal::cereal with v1.3.1 #862

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

Open
zachcran opened this issue Apr 20, 2025 · 0 comments

Comments

@zachcran
Copy link

Did you search for related issues (including closed issues)?

Yes.

Describe the Issue

Release version 1.3.1 (specifically PR #659) updated the installed CMake target from cereal to cereal::cereal. This breaks downstream builds that use find_target() to pull in cereal as a dependency, since they would have been referencing it as cereal.

Proposed Solutions

First, I want to mention that I love the move to more modern CMake conventions like namespacing installed targets! However, I feel like this change deserves a bit more warning than it received. Here are a few suggestions I can think of to help notify users of the change and transition more smoothly:

  • Update the text of release v1.3.1 to explicitly note that the CMake target was changed. Something like "CMake installed target was updated from cereal to cereal::cereal." would be sufficient for me.
  • I could not find documentation on using the CMake build, but if that exists, ensure that it is up to date and warns users of the change.
    • If there is no CMake-specific documentation, a notice in the README.md or on the website would also work.
  • Changing the exported target name seems like it warrants more than a patch version increment to me. I am not sure if the project adheres strictly to semver, but, arguably, the installed CMake target name is part of the public API of the project, so a major version increment would be in order due to broken backwards-compatibility of the public API. This would help signal to downstream project managers that they need to check their builds.
  • (To facilitate the transition more) Provide a new patch version that provides both target names, as well as a deprecation notice for the old target name. In this case, release version 1.3.1 and 1.3.2 patch notes would also need to be updated to note that they contain the breaking change. As far as I know, there is not a great way to export both the namespaced and non-namespaced versions, although I can think of a few ways that would probably work and am open to discussing further if there is interest in this route.
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

1 participant