Enable multiple package versions side-by-side.

[destenson]

This sounds like it might be tricky, but it's much needed for many projects that rely on a specific version of a library. Take Boost, for example, its public APIs can change significantly from version to version and many projects find a version that works for them & stick with it. And as of now, those projects are alienated from participating in this vcpkg ecosystem.

[bagong]

I think the way offered to use older version is to move back in git history, which means working with older versions of all libraries in the project. Mixing versions of different history levels is more involved but possible, if the versions combine ;). I know of no way to control versioning e.g. as part of defining a "triplet", it would all have to be handled via git history. I think that option is avoided for now, as you say it leads to considerable complications. For foundational libraries like boost and qt it would be nice to be able to address versions, but it's not trivial to implement that ;)

[cmpute]

I think the proposal is brilliant. Just like PyPI where I can do pip install numpy=1.10, I think it should be great to have an option to install certain version of packages, that's quite a useful feature if we have pkg install <pkg>[=<version] or sth like that.

[arthur-tacca]

which means working with older versions of all libraries in the project

Not only older versions of libraries, but fewer libraries because more get added over time.

[horenmar]

This would also help to people who provide library and are making a large breaking change in next version: I want to provide both current stable version and a semi-stable preview of the next version, so people who want features that are breaking can keep using vcpkg.

I could probably create a different port folder and ask for it to be accepted into the repository, but it seems like a crude workaround, and I fear we would end up with ports/ looking like

...
boost-1.61.0
boost-1.62.0
boost-1.63.0
boost-1.64.0
...

[justinmeiners]

@horenmar I thought of the same rudimentary workaround.

I like the idea that the port structure is very simple, but I think versions could be added in a simple way.

Perhaps the port tree could look like

boost/
     1.61/
         CONTROL
         portfile.cmake
     1.62/
         CONTROL
         portfile.cmake

Adding a new version would require copying the previous folder, and updating the commit ref and version information in the portfile and control. A patch update could just adjust the commit id of an existing version. Users could still lock their patch by saving the ports directory.

[Fleischner]

Its already difficult enough to fix problems with the most recent packages and keep momentum. So I don't think it's the best idea to add support for multiple minor versions (despite major changes of course, as python2/3 qt4/5 etc)

I proposed a way to enable users to "freeze" their ports some time ago:
#3022
It works very well for us. Short summary: Instead of using ports from the 'ports'-directory we use a 'ports-selected'-directory that only contains ports we use and all those ports will be build. This way we can always easily pull the head version of vcpck/ports without changing anything. A second pull(copy port from ports to selected) makes the actual port upgrade. This way we can migrate at our own pace if some upgrades conflict with some of our custom ports.

Also we stay with the vcpck design and use multiple vcpck installations to manage different versions of our library-set. We use following approach for switching, and it works also very well:
#3021

[LilyWangL]

Thanks for posting this issue. Closed as duplicate of #1681.