Open
Description
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
cerealtocereal::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.
Metadata
Metadata
Assignees
Labels
No labels