v0.2.1 - Maven Central gets 0.2.x, and the crate gets its signature

A release-machinery fix. No binding's API changes — everything 0.2.0 added is unchanged and still there. What changes is that two things 0.2.0 couldn't finish are now finished.

0.2.0 was a partial release:

	0.2.0	0.2.1
crates.io, RubyGems, PyPI, NuGet	published	published
Maven Central	never published	published
crates.io provenance	unsigned	signed

If you use the Java binding, or if you verify provenance, this is the release you want. Everyone else can take it or leave it.

Java: 0.2.0 never reached Maven Central

Sixteen @param tags were missing from the destination-buffer and raw-byte SQL-order methods 0.2.0 introduced, and javadoc -Xwerror correctly refused to build the docs jar — which stopped the Maven publish after crates.io, RubyGems, PyPI and NuGet had already published.

0.2.0 is absent from Maven Central and will stay absent. The version number is spent on five other registries, so it cannot be published now. Java consumers should go straight from 0.1.1 to 0.2.1, which carries everything 0.2.0 added — the fillV6/fillV7 overloads over UUID[] and byte[], and the in-place byte[] SQL-order transforms.

The gate that caught this had existed all along. It simply never ran anywhere it could catch anything: C# and Rust get their doc enforcement from compilation CI already performs (CS1591 with warnings-as-errors, #![deny(missing_docs)]), but Java's -Xwerror only fired during the Maven publish. javadoc now runs on every pull request, on the same leg that already compiles Java.

The crate is signed again

On 0.2.0 the attestation step ran after cargo publish and could not find the packaged .crate, so the crate uploaded and the signing failed. A crates.io publish is irreversible — yank hides a version, it never deletes one, and the number can never be reused — so the 0.2.0 crate has no provenance attestation and cannot be given one. Even re-tagging wouldn't help: the commit sha rides inside .cargo_vcs_info.json, so a different commit produces different bytes.

Its integrity is still checkable — cargo verifies every download against the checksum crates.io's index records — but its provenance is not.

The pipeline now packages, attests, and only then publishes, so the same failure would stop the release while it is still reversible. Attesting the packaged file rather than the uploaded one is sound because a .crate is byte-identical wherever it is produced from the same commit; that was measured against both v0.1.1 and v0.2.0's published checksums, not assumed.

gh attestation verify hyperuuid-0.2.1.crate \
  --repo SkunkWerkx/HyperUuid --signer-repo SkunkWerkx/.github

crates.io publishing is tokenless

Publishing now uses crates.io Trusted Publishing over OIDC instead of a stored API token — short-lived credentials minted per run and revoked when the job ends. Consumer-invisible, and recorded only because it changes what a compromise of this repository's secrets could reach.

Worth knowing if you're setting up your own: a Trusted Publisher configuration can only be created after the crate already exists, and crates.io has no equivalent of PyPI's pending publishers. A brand-new crate needs one manual token publish first.

The rest of 0.2.0 was already sound

Before cutting this release, every other 0.2.0 artifact was verified by downloading it from its registry and running gh attestation verify — 20 artifacts, all passing:

• PyPI 6/6 wheels · RubyGems 7/7 gems, including aarch64-mingw-ucrt · NuGet the published .nupkg
• Packagist / Swift / Go — 6 native libraries, which covers all 18 committed paths: they are only 6 distinct git blobs, one per RID, shared across the three trees by design

So the gap really was just the crate and Java.

Upgrading

Drop-in from 0.2.0 for every binding, and the first available 0.2.x for Java. Same API, same behaviour, same native core — only the release plumbing changed.

Full changelog: v0.2.0...v0.2.1