For fixing the CI failure:

please use version instead of version-string in the vcpkg.json file.

AFAICT 1.1.1-3651f232c27074c4ceead169e223edf5f00247c5 is not a valid version.
https://vcpkg.io/en/docs/users/versioning.html#version

I took the time to check upstream.
All what was added in the chosen REF over 1.1.1 is a particular cast:
ClockworkOrigins/clockUtils@1.1.1...master
From this background, I would suggest to use "version": "1.1.1", and just add a note to the REF in the portfile.
(Alternatively, actually use REF 1.1.1 and add this single change as a patch, for maximum transparency.)

I took the time to check upstream. All what was added in the chosen REF over 1.1.1 is a particular cast: ClockworkOrigins/clockUtils@1.1.1...master From this background, I would suggest to use "version": "1.1.1", and just add a note to the REF in the portfile. (Alternatively, actually use REF 1.1.1 and add this single change as a patch, for maximum transparency.)

This is more of an opinion.

The practice is that if a port - especially if the repo wasn't updated for 5 years - to use version-date to point at the latest commit on master. I am pretty sure that the appended commit id broke the versioning scheme anyway. I would prefer patching if we expected a new release. I don't like the idea to use 1.1.1 because there already was a version 1.1.1. In this case I would need to update port-version which is incorrect as well.

I took the time to check upstream. All what was added in the chosen REF over 1.1.1 is a particular cast: ClockworkOrigins/clockUtils@1.1.1...master From this background, I would suggest to use "version": "1.1.1", and just add a note to the REF in the portfile. (Alternatively, actually use REF 1.1.1 and add this single change as a patch, for maximum transparency.)

This is more of an opinion.

Yes, this is my opinion. Of course there are also arguments:

• Upstream version schemes are generally also adopted by other package repositories, and using the same scheme facilitates comparison, e.g. on repology.org.
• Upstream versions are what consumers of our ports usually refer to.

The practice is that if a port - especially if the repo wasn't updated for 5 years - to use version-date to point at the latest commit on master.

IMO this is more another opinion than common practice. The differentiated version schemes don't exist for a long time. And very often, version-date refers to the date of the port change, not the upstream change.

I am pretty sure that the appended commit id broke the versioning scheme anyway. I would prefer patching if we expected a new release. I don't like the idea to use 1.1.1 because there already was a version 1.1.1. In this case I would need to update port-version which is incorrect as well.

If we don't expect a new version, we could just stay with version-string. It gives both the approximate version and the actual commit.

If we don't expect a new version, we could just stay with version-string. It gives both the approximate version and the actual commit.

This is what I want as well, but GH Actions doesn't like it.

If we don't expect a new version, we could just stay with version-string. It gives both the approximate version and the actual commit.

This is what I want as well, but GH Actions doesn't like it.

Yes, but the GH action didn't propose a change, it just failed with an error. Other port authors already went through version scheme ping-pong because of this. My initial comment was meant to save you from this pointless exercise.

GH Actions doesn't like it.

Cf. #24011 (comment)

Thanks!