vcpkg releases?

[danrbailey]

Why do releases stop at 2020.01?

GitHub Actions is using "2020.02.04-nohash" in their Windows images (https://github.com/actions/virtual-environments/blob/master/images/win/Windows2019-Readme.md#vcpkg) and AppVeyor is intending to update to "2020.02.04-nohash" (https://github.com/appveyor/ci/issues/3348) soon.

I can find no useful reference to what "2020.02.04-nohash" is and why it's the one that's being favored by CI systems.

[ghost]

Never Mind - I misunderstood the question

What do you get when you type in:

->.\vcpkg.exe version
Vcpkg package management program version 2020.02.04-nohash-external

If one does not get the above results, one may need to run:
- git pull from the _vcpkg-root_ (get the latest updates)
- run .\bootstrap-vcpkg.bat from the _vcpkg-root_ (recompile and link the vcpkg executable)

[PhoebeHui]

@dan-shaw, does the release in progress? I noticed that the latest release version is 2020.01 from Victor in https://github.com/microsoft/vcpkg/releases, and our vcpkg package management program version is 2020.02.04 now.

[linquize]

No tag for 2020.02 yet

[davidhunter22]

I'm also interested in this. Are monthly tags no longer a thing? We find these useful as it less error prone to communicate use library versions in "2020.01" than to use a Git commit id.

[heydojo]

I can find no useful reference to what "2020.02.04-nohash" is and why it's the one that's being favored by CI systems.

Cache. There is a large amount of cache in the background underpinning CI/CD systems.
Rebuilding large amounts of cache can take a long time. I know this because a while back the cache had to be purged here due to some reason or another and it took about a day and a half for the CI/CD system to come back online.
And so, if you also bump the base commit which the CI/CD system is using, that's a lot of cache to rebuild.

When the CD/CI system checks the code from a merge request for vcpkg, it patches over what is already there. That's why you'll often see in threads maintainer's merge proposals being version bumped as they pull changes into their tree as the patches are reviewed. That's them keeping the code up to date so that the commits merge cleanly and builds succeed against the latest version of the code because the CI/CD system doesn't have the latest version of the code.

Due to the fast paced nature of vcpkg, the version string is likely more of an _internal_ indicator of a large feature, development milestone or stabilisation point.
It is not inherently a great _external_ signifier.

Due to how git works, no one needs to rely on "releases" being tagged. Because all proposed merge requests to the master tree go through the CI/CD system. CI/CD provides by it's very nature; stability. This completely negates the old software development method of providing meaningful stable release versioning. It means that if you pull from vcpkg master at any given time, the possibility of stability is extremely high. It also helps development of vcpkg for you to pull from master and help fix/report any problems you may find.

I don't personally ever look to tagged "releases" when building things against vcpkg. I go by commit. I recommend to anybody else to do the same. And as far as vcpkg in Appveyor goes, you can just move into the dir and pull the latest vcpkg from github master using:

git pull

My opinion here is that vcpkg's versioning should be unimportant to anyone outside of Microsoft involved in analytics. I assert that the most sensible way to use vcpkg's code is to git merge the HEAD of the master branch to a specific commit.

For example:

git merge 42ad12f91d62a6533d909d8b5ee3a46009c2a10a

and from then on, to only pull the latest code periodically. And to suit your own development schedule. Not vcpkg's.

In short, it's great that you have the time to keep bumping your upstream dependencies but your overall focus should not shift away from actually working on the application you are building and instead towards updating it's dependencies simply because upstream created some arbitrary tag.
To anyone who doesn't understand what I mean, wait until your application has a huge number of depreciated compiler warnings after several dependency version bumps because you didn't have the time to fix what had changed. You need to schedule time to fix depreciated warnings as they can often be non-trivial to fix.

I'm not advocating that anyone needs to agree with me but I hope this at least helps a few people.

[PhoebeHui]

The '2020.02.04-nohash' is release version for vcpkg tools, not release frequently if there is no significant changes.

[linquize]

There is 2020.04 tag