[exprtk] Add version 0.0.3 2024-01-01

[ArashPartow]

• Changes comply with the maintainer guide.
• SHA512s are updated for each updated download.
• The "supports" clause reflects platforms that may be fixed by this new version.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.

Note: This PR needs to be merged after the PR #42996 has been merged.

Closes the following PRs: #42173, #40270, #33571, #30058, #29955, #29801, #29775, #29665, #38756

---

@PhoebeHui / @jimwang118 / @JonLiu1993 / @LilyWangLL

[dg0yt]

Not resolved: Use lower-case SHA512 and git ref SHA, #42996 (comment).

[dg0yt]

Not resolved: Use copyright from upstream repo.

[ArashPartow]

@dg0yt It seems you're having troubles so early on in the new year. Hope things work out for you.

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[vicroms]

@ArashPartow

The review comments made by @dg0yt are made in good faith. dg0yt is a longtime contributor to vcpkg and cares about the quality of the ports in the registry.

Regarding specific items:

Versioning

Currently, the exprtk port uses version-date and pins specific Git commits, both #42996 and #43036 maintain the status quo. The version-date scheme is intended for projects that don't intend to publish versioned releases and prefer following a live-at-head approach.

The comments made by @dg0yt and @JavierMatosD suggest changing the scheme to version and updating REF to use the published version tags. Those comments were made in line with our maintainer guideline of preferring upstream's versioning schema. Also, given that Conan and Spack have the exprtk library under versions 0.0.2 and 0.0.3, using them provides familiarity to users.

Copyright

PR #42996 for version 0.0.2 contains a checked in copy of the MIT License text. The maintainer guidelines state that if the license is not available in file form in the source code, then the port should instruct users on how to find the license themselves. The approach in #43036 of using a header file is an acceptable compromise.

SHA512 casing

We recently had a regression with regards to uppercase SHA512s contained in the vcpkg-tool.json file that broke some user scenarios, and while ports were not affected, we would prefer avoiding an issue with custom tooling built on top of vcpkg by keeping a consistent casing for all SHA512. We have updated our maintainer guideline to reflect this requirement.

[vicroms]

Thanks for the PR, I merged #43193 since it conforms to the maintainer guidelines.