Shouldn’t I git-switch to a stable release before running bootstrap-vcpkg.bat?

[Jayman2000]

I’m currently working on contributing to Descent 3. The build instructions for Descent 3 say:

git clone https://github.com/microsoft/vcpkg.git
cd vcpkg && bootstrap-vcpkg.bat

I noticed that the instructions in the vcpkg repo say something similar:

> git clone https://github.com/microsoft/vcpkg
> .\vcpkg\bootstrap-vcpkg.bat

Won’t that cause you to use the latest unstable release of vcpkg? I don’t really know anything about vcpkg, but wouldn’t it make more sense to do this?

git clone https://github.com/microsoft/vcpkg
cd vcpkg
git switch --detach 2024.04.26
bootstrap-vcpkg.bat

[Neumann-A]

latest vcpkg binary should always be stable. If you use manifest mode + baseline you get what you ask for.

[dg0yt]

> git clone https://github.com/microsoft/vcpkg
> .\vcpkg\bootstrap-vcpkg.bat

Won’t that cause you to use the latest unstable release of vcpkg?

No. The git tags aren't more stable than the HEAD of master. There is no specific quality process for the git tags. Except not letting getting the newest tag too old.

I don’t really know anything about vcpkg, but wouldn’t it make more sense to do this?

git clone https://github.com/microsoft/vcpkg
cd vcpkg
git switch --detach 2024.04.26
bootstrap-vcpkg.bat

No. There is no benefit in terms of quality with regard to the HEAD of master.

[dg0yt]

If there’s no benefit to using releases in terms of quality, then why does the vcpkg repo do releases at all?

AFAICT there was a time when releases had a meaning. When vcpkg stopped making releases, users didn't stop checking out the last release and reporting bugs for outdated port versions.

[StarGate-One]

You can always clone the vcpkg-tool repo and build vcpkg from source - there you will have the latest vcpkg binary.

[Jayman2000]

@Neumann-A

Why did you assume that releases are more stable?

Pretty much all of the projects that I’ve ever seen do one of two things. They either encourage regular users to use the latest release instead of the latest HEAD or they don’t do releases at all. I thought that there was a good chance that vcpkg did the same thing, but I wasn’t sure, so I asked the question.

Also, I’m realizing that I may have phrased the question poorly. When I say “latest stable version”, I mean “latest release that isn’t a pre-release”. When I say “latest unstable version”, I mean “latest HEAD”. That’s how the Nixpkgs project uses those terms, but I’m realizing that that’s probably not how most people use those terms. I wasn’t commenting on how likely things were to break.

---

@StarGate-One

You can always clone the vcpkg-tool repo and build vcpkg from source - there you will have the latest vcpkg binary.

That’s true, but I don’t really see how it’s relevant.

[AugP]

We do regular releases to keep people updated on what the changes are between different time periods and because some companies have requested a more structured release process and associated communications that they can follow. These companies tend to pin to specific releases and request the rest of their organization to be pinned to the same release at the same time. It's easier to tell your team "Pin to the April 2024 release" than "Pin to this specific git commit".

We have two repos where we publish releases:

1. Registry releases: github.com/microsoft/vcpkg/releases (this repo)
2. Tool releases: github.com/microsoft/vcpkg-tool/releases

The tool releases are more meaningful since they impact the vcpkg binary directly. Registry releases mainly consist of changes to the ports in the open-source registry and thus impact your default baseline of available ports and versions. We also enable the latest available version of the vcpkg tool when you update the registry. We also tend to summarize notable changes in the tool in our registry releases if there was a tool update since we get a lot more visitors to this repo than the tool one. Lastly, we publish blog posts summarizing the more notable changes in releases here: https://devblogs.microsoft.com/cppblog/

The reason stability isn't really an issue whether you're pinned to HEAD or a particular release is that the tool itself is released separately from a different repo and you will be getting the latest stable one when you run the bootstrap script that ships with this repo.

[Jayman2000]

That was a really helpful explanation. Thank you!