Replies: 1 comment
-
At my company we use Option 1. If a project needs both major versions that is an error and up to the developer to fix. The 2nd CON you list is mostly theoretical, but I don't know how big your org is. For example, we renamed the 1.x package to "XXXXX-legacy". and the 2.x package remained "XXXXX". In vcpkg you indicate "XXXXX-legacy" but in CMake they have the same name. Option 3 as you describe sounds like a maintenance nightmare. Also how do you select which major version you are using? vcpkg has avoided listing maximum versions or using version ranges/regex's until now which honestly is an improvement (having worked with conan for some time) making everything easier to reason about. |
Beta Was this translation helpful? Give feedback.
-
Hi.
In the context of custom registry used for company internal libraries we are often faced with the need to support multiple major versions of the same library for different projects.
For example, we might have libA that support 1.X and 2.X and we might still need to publish 1.X and 2.X in parallel with potentially very different portfile.cmake between versions.
What would be the best strategy to maintain such versions in our custom registry ?
Here are the options we have considered
Option 1 : Make them different ports
Pros
Cons
--> This option simply does not work !
Option 2 : Use multiple registries
Custom registry being a git repository it can be cloned or branched. As such, it might be possible to clone or branch it to make different versions of the port.
Maintainer need to update the right clone/branch for the targeted version.
Consumer need to pick-up the right clone/branch for the version he needs.
Pros
Cons
--> This solution seems ok for a limited number of libraries but does not scale at all.
Option 3 : Create subdirectories into the port
Make supported versions subfolders of the ports
In this approach, maintainer directly modify the corresponding version it needs to publish (e.g. libA/1.X). Then the content is copied to "libA" so that the requirement stating that each port should have "portfile.cmake" and "vcpkg.json" at its root is fullfilled. Obviously all this publishing process would be enclosed in a script to avoid the need to do it by hand.
Pros
Cons
But maybe this "issue" could be mitigated if we were not updating "versions/baseline.json" if the published version is lower than the current one in the baseline as our versions are actually semantic. Doing so we would ensure that if no constraint is specified you always get the latest.
--> This looks like the best option
Questions
Thanks for your feedback !
Beta Was this translation helpful? Give feedback.
All reactions