3.10.1 zip json.hpp has version number 3.10.0 instead of 3.10.1

[Andreas-Schniertshauer]

The version number in json.hpp of zip file 3.10.1 is 3.10.0 instead of 3.10.1,
see comment line 4 and line 35 #define NLOHMANN_JSON_VERSION_PATCH.
Maybe you want also adjust the comment in line 9 Copyright (c) 2013-2019 to 2021.

[nlohmann]

Thanks for reporting! The whole tag seems wrong. Yesterday was the first release with a new release script, and apparently something went wrong. :-/

[Andreas-Schniertshauer]

The good news is that 3.10.1 (zip) compiled with Visual Studio 2019 16.11.1 and all tests (Debug/Release) succeeded.

[dvzrv]

As the tag is not on the correct commit, this also means that the PGP public key 797167AE41C0A6D9232E48457F3CEA63AE251B69 can not be used to verify it.

For packaging purposes on Arch Linux I will use 1fd2213 instead, as it is (AFAICT) the one that should have carried the tag.

[xvitaly]

@nlohmann Please move tag to 1fd2213 commit.

[nlohmann]

How can I move tags?

[xvitaly]

How can I move tags?

git tag -d v3.10.1
git push --delete origin v3.10.1

Then create a new one as usually.

[dvzrv]

I would not advise to remove a tag and tag another commit. It will break any downstreams that already rely on e.g. the generated source tarball (it's contents and checksum will change if you do this).

The cleaner solution is always to just create a new release (e.g. v3.10.2).

[xvitaly]

The cleaner solution is always to just create a new release (e.g. v3.10.2).

Agree.

[nlohmann]

I will prepare a new release soon. I have to check with the release script to check why the tags were not correctly set.

[nlohmann]

So this is what happened:

I am using git flow to manage release branches. I created the release branch with

git flow release start 3.10.1

did all the changes and concluded with

git flow release finish 3.10.1

This created the tag 3.10.1, but not v3.10.1, because by default, the config entry versiontag is set to the empty string.

Then I had the release draft for tag v3.10.1 and a pushed tag for 3.10.1. I was confused, removed the 3.10.1 tag and published the release, which created the v3.10.1 tag. Apparently at that point, the changes to master and develop were not yet pushed.

The attached files in the release were correct, because I uploaded them from the working directory of my release script.

This is what I'm going to change:

• After creating the working copy for the release branch, I execute the command

  git config gitflow.prefix.versiontag v
  

  to make sure the prefix is correctly set when the release tag is created.

• I added the missing

  git push --tags
  

  call to make sure the tag is pushed to GitHub.