mingw-w64-curl: update to 7.87.0

[gitforwindowshelper]

This closes git-for-windows/git#4191

[dscho]

/deploy

The workflow run was started

[dscho]

@rimrul I kicked off https://github.com/git-for-windows/git-sdk-64/actions/runs/3747868453 and https://github.com/git-for-windows/git-sdk-64/actions/runs/3747868453. After that, we only need to release a new Git for Windows, I think.

Maybe we can find an excuse for a tiny git-for-windows/git PR so that we can use the /git-artifacts and /release commands?

[rimrul]

I guess we could drop https://github.com/git-for-windows/git/blob/main/.github/workflows/monitor-components.yml#L68-L69

now that we found out it hasn't updated in ages.

Though we might need to think about how we get updates for the other two in the gpg GitHub org.

[dscho]

I guess we could drop https://github.com/git-for-windows/git/blob/main/.github/workflows/monitor-components.yml#L68-L69

now that we found out it hasn't updated in ages.

Good point.

Though we might need to think about how we get updates for the other two in the gpg GitHub org.

Another good point...

[dscho]

Oh my. This gnupg.org home page is a mess. Now it says that the current version is 2.4.0. But there is nowhere any news entry to be seen about that version. And https://gnupg.org/download/git.html claims that 2.4.0 is a development version and the stable version is 2.2.41. Which was also not announced anywhere on the front page.

I fear we might have to do a lot of manual work and stop trusting that web page altogether, as far as automation goes. Instead, we'll have to monitor https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=tags, https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=tags and https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=tags, and then decide on a case by case basis whether the newest tag actually corresponds to any stable release.

What a mess.

As far as that "excuse" PR goes, I think I'll instead go for silencing the compiler warnings of mimalloc when compiling in DEVELOPER mode.

[rimrul]

Oh my. This gnupg.org home page is a mess. Now it says that the current version is 2.4.0. But there is nowhere any news entry to be seen about that version.

There is. It's just titled

25 Years of GnuPG (2017-12-20)

I fear we might have to do a lot of manual work and stop trusting that web page altogether, as far as automation goes. Instead, we'll have to monitor https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=tags, https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=tags and https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=tags, and then decide on a case by case basis whether the newest tag actually corresponds to any stable release.

That's probably our best solution, even if I don't like it.

[dscho]

25 Years of GnuPG (2017-12-20)

2017? Seriously? Have I missed some travel back in time?

[dscho]

I fear we might have to do a lot of manual work and stop trusting that web page altogether, as far as automation goes. Instead, we'll have to monitor https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=tags, https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=tags and https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=tags, and then decide on a case by case basis whether the newest tag actually corresponds to any stable release.

That's probably our best solution, even if I don't like it.

I opened git-for-windows/track-website-changes#9 for any further discussion on this.

[rimrul]

25 Years of GnuPG (2017-12-20)

2017? Seriously? Have I missed some travel back in time?

Apparently. I've just had another look if I messed up copying&pasting that and it still says 2017.