Reconcile 0.1.1 and 0.1.2: one misrepresents its source, the other has no package #14

Outcome

Two published versions do not mean what they claim. Decide what to do about each, before anyone depends on them.

WinDevicesNet 0.1.1 on nuget.org

Two defects, both invisible to a consumer:

It does not correspond to its tag. It was built from a main that was six commits ahead of v0.1.1. The tag points at the initial commit; the GitHub release of that name carries January zip assets sharing nothing with the published package. This is what motivated the exact-tag guard added in #6.

It was built with the wrong toolset. windows-latest had silently become windows-2025-vs2026, so the native library came from the VS 2026 toolset. dumpbin on the shipped binary:

WinDevices.dll → MSVCP140.dll, VCRUNTIME140.dll, VCRUNTIME140_1.dll

CMake defaults to /MD, so the toolset sets the minimum Visual C++ Redistributable a consumer's machine must carry, and v14x runtimes are compatible forward but not backward. It loaded during verification only because that workstation had a current redistributable installed. A clean endpoint may not. #7 pinned the build to windows-2022 afterwards; 0.1.3 is correct.

Unlisting is the proposed action. The version cannot be deleted from nuget.org, and nothing depends on it yet, so the cost is zero and the misrepresentation goes away. This is a manual step: the Trusted Publisher policy carries the Push scope only.

Tag and release v0.1.2, with no package

v0.1.2 was tagged and its GitHub release published, but publish-nuget.yaml was unparseable at that moment (see #12), so nothing reached nuget.org. main then moved past the tag, and building 0.1.2 from main afterwards would have reproduced exactly the provenance defect described above, so it was deliberately not chased. v0.1.3 was cut instead.

The result is a version that exists as a tag and a GitHub release but will never exist as a package. Either delete the tag and release, or keep them with a note in the release body saying no package was produced and pointing at 0.1.3.

Deleting is proposed: a release nobody can install is only a source of confusion, and the history it marks is preserved by v0.1.3 which contains it.

Acceptance

• 0.1.1 is unlisted on nuget.org, or a recorded decision explains why it stays listed.
• v0.1.2 is either removed, or its release body states that no package exists and directs readers to 0.1.3.
• 0.1.3 remains the version documented in the README and QUICKSTART examples.