Custom registry : Maintaining multiple major versions in parallel

[MacNic]

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

ports
      |--- <libA>
      |--- <libA1>

Pros

• It's "standard" vcpkg usage

Cons

• libA and libA1 are actually not 2 distinct libraries and they cannot be installed alongside. So it seems wrong to define them that way
• If another library in the registry was using libA and referencing it through vcpkg.json as dependency, then you are screwed as you have no way to tell if it should be libA or libA1 as this will ultimately be a consumer decision

--> 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

• It's "standard" vcpkg usage

Cons

• As there might be many many different libraries having many different versions at the same time, it become completely unpractical to maintain so many clone/branches for each library that need too.
• From a consumer perspective, it looks awfully complex to have to specify that many different registries in its vcpkg-configuration.json when it would have been much more logical to constraint versions using "standard" vcpkg versioning constraints from a single registry if need be.

--> 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

ports
      |--- <libA>
          |--- portfile.cmake
          |--- vcpkg.json
          |--- <1.X>
              |--- portfile.cmake
              |--- vcpkg.json
          |--- <2.X>
              |--- portfile.cmake
              |--- vcpkg.json

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

• All the supported versions are visible at a glance in the same repository so it's easier for maintainers
• There is still only one registry so it's easy for consumer to reference
• Version selection on consumer side can be made possible through standard vcpkg version constraints

Cons

• Versions can now be published "out of order" (e.g. 2.1 -> 2.2 -> 1.5 -> 2.3 -> 1.6) so if consumer is not specifying any constraint (as it might be typical in development branch) it might be surprising (and wrong) to retrieve a version that is not the "latest" (e.g. 1.6 instead of 2.3).

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

• What do you think of option 3 ?
• Is there any drawback we should worry about ?
• Do you have better ideas to ease maintenance of multiple major versions in parallel in the vcpkg ecosystem ?

Thanks for your feedback !

[kevin--]

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.
This helps porting to the new version in the future, and assuming the libraries are properly semver'd then a major version change should either lead to a configure time error or a compile time error (otherwise it will probably work?)

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.