hyperuuid-wasm 0.8.0 → 1.0.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: ba3ad5f11b5973d062a7dfff6d85f657a809873d39b166c7837ee30d99092a2d
-  data.tar.gz: efde3c81dba7991a8238aaa2929f0abcf026c8c6b6b6454af334a2c6473860d1
+  metadata.gz: 23b7842046b78dff468073474bdb004a03c6d4710ff13a7ff3f048c879d141f9
+  data.tar.gz: 04204e9e6c775cb35a8370b53ffd8fc8c7538ad9220fffc5a05fc7e76c07ec7a
 SHA512:
-  metadata.gz: 5e10e781dad666e3734d3bb01c05cf1eeb537e309e5a2e733561153a02bca3817cfe1b6358b4a2129eb86446be2f79cd0d72c210efbea37b0600c2776ed716e0
-  data.tar.gz: cf012e5d94e0bbe5c9edd0d9c437fef470238deedad2871ab2aa74d3fc09323b07a47de12e98d9bbb7fb9e5a0cb7d26e98d3b76320f36930b84d904310405901
+  metadata.gz: b1dd276963bf50735b2e9f7cd1be16dbeb7c7edebef8c027471cbaf6686237ef971b91f87f328a42650232b25e2bd5bd5d0cdb39309674fe2f5f743b58553a0d
+  data.tar.gz: 9e2ee0585a21dbdd3266ef635134e2013a09b3cb5538427a0b71df0e9126d4d9d3fbc7f8a0dc73f9b4ed5579c3f1c181e8d2de73b54e04c240b6e1eb8701637e

data/README.md

@@ -4,10 +4,10 @@
 [![RubyGems](https://img.shields.io/gem/v/hyperuuid.svg)](https://rubygems.org/gems/hyperuuid)
 [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://github.com/SkunkWerkx/HyperUuid/blob/master/LICENSE)
 
-**Ruby's own stdlib stops at `SecureRandom.uuid` and `SecureRandom.uuid_v7` — random v4 and v7, one at a time. No v5, no v6, no batches, no SQL Server order. This gem is the whole RFC, with zero gem dependency beyond `Fiddle` (which ships with every Ruby install) — and it's faster than `SecureRandom.uuid` too.**
+**Ruby's own stdlib stops at `SecureRandom.uuid` and `SecureRandom.uuid_v7` — random v4 and v7, one at a time. No v5, no batches, no timestamp read-back, no SQL Server order. This gem fills that in, with zero gem dependency beyond `Fiddle` (which ships with every Ruby install) — and it's faster than `SecureRandom.uuid` too.**
 
-RFC 9562 UUID v4 (random), v5 (deterministic), v6 and v7 (time-sortable) generation, with
-two backends sharing one public surface. Ruby 3.3 is the floor. The fast path is a native
+RFC 9562 UUID v4 (random), v5 (deterministic) and v7 (time-sortable) generation, with a
+version 8 SQL Server order for v7 and two backends sharing one public surface. Ruby 3.3 is the floor. The fast path is a native
 extension built with [Magnus](https://github.com/matsadler/magnus) — the Rust core linked
 directly into the Ruby VM, auto-selected when loadable — which redefines the low-level
 `Runtime` methods in place on require; everything above them (`Uuid`, the module doors and
@@ -22,13 +22,12 @@ require "hyperuuid"
 
 id = HyperUuid.new_v4
 id2 = HyperUuid.new_v5(HyperUuid::Namespaces::DNS, "example.com")
-id3 = HyperUuid.new_v6
-id4 = HyperUuid.new_v7
+id3 = HyperUuid.new_v7
 
-id4.timestamp # recover the embedded UTC Time
-id4.timestamp(raise_on_mismatch: false) # nil instead of raising if id4 isn't an RFC 9562 v6/v7
-id4.rfc?(7) # the RFC 9562 variant and version 7, the guard before trusting its fields
-sql = id4.to_sql_order # byte order SQL Server's uniqueidentifier needs to sort by creation order
+id3.timestamp # recover the embedded UTC Time
+id3.timestamp(raise_on_mismatch: false) # nil instead of raising if id3 isn't an RFC 9562 v7
+id3.rfc?(7) # the RFC 9562 variant and version 7, the guard before trusting its fields
+sql = id3.to_sql_order # a version 8 laid out so SQL Server's uniqueidentifier sorts by creation order
 sql.timestamp(layout: :sql_server) # read straight from SQL order, no round trip
 
 # One native call, one random-bytes fetch, one counter reservation for the whole batch:
@@ -41,9 +40,9 @@ batch = HyperUuid.new_v7_batch(1000)
 |---|---|---|
 | `new_v4` | `Uuid` | — |
 | `new_v5(namespace, name)` | `Uuid`, the same one for the same pair | a `Uuid` namespace (`Namespaces::DNS`/`URL`/`OID`/`X500`, or your own) and a `String` name — text is hashed as UTF-8, a binary String as its bytes, and it may be empty |
-| `new_v6(time = nil)` `new_v7(time = nil)` | `Uuid` | nothing (now), a `Time`, or an Integer of Unix-epoch milliseconds |
-| `new_v6_batch(count, time = nil)` `new_v7_batch(count, time = nil)` | `Array` of `Uuid` | a count (at most `MAX_V7_BATCH` for v7), and the same time forms |
-| `new_v6_batch_bytes(count, time = nil)` `new_v7_batch_bytes(count, time = nil)` | one binary `String`, 16 bytes per UUID | as the batch doors — see [Bulk generation into bytes](#bulk-generation-into-bytes) |
+| `new_v7(time = nil)` | `Uuid` | nothing (now), a `Time`, or an Integer of Unix-epoch milliseconds |
+| `new_v7_batch(count, time = nil)` | `Array` of `Uuid` | a count (at most `MAX_V7_BATCH`), and the same time forms |
+| `new_v7_batch_bytes(count, time = nil)` | one binary `String`, 16 bytes per UUID | as `new_v7_batch` — see [Bulk generation into bytes](#bulk-generation-into-bytes) |
 | `native_version` | the loaded core's `"major.minor.patch"` | — |
 | `available?` | `true`/`false`, never raising | — |
 
@@ -56,50 +55,70 @@ runtime dependency on the `uuid` gem:
 | `Uuid.new(bytes)` | wraps 16 raw RFC 9562-ordered bytes |
 | `Uuid::NIL` `Uuid::MAX` | the RFC 9562 §5.9/§5.10 special values |
 | `#bytes` `#to_s` | the frozen binary String, the hyphenated text |
-| `#version(layout: :rfc9562)` | the version in that layout: the nibble, 0-15, in RFC order; 6 or 7 for a SQL-ordered v6/v7 in `:sql_server`, 0 when the bytes don't form one |
+| `#version(layout: :rfc9562)` | the version in that layout: the nibble, 0-15, in RFC order; in `:sql_server`, 7, the version a SQL-ordered value was converted from, and 0 when the bytes aren't one |
 | `#variant` | the RFC 9562 §4.1 variant, as a Symbol: `:rfc9562` (every UUID this gem mints, and the only variant with versions), `:ncs` (Nil among them), `:microsoft`, `:future` (Max among them) |
 | `#rfc?(version, layout: :rfc9562)` | whether it is an RFC 9562 UUID of that version: the variant and the version together. A version outside 0-15 is `false` |
-| `#timestamp(raise_on_mismatch: true, layout: :rfc9562)` | the UTC `Time` embedded in an RFC 9562 version 6 or 7 UUID held in that layout, in one native call that checks the variant as well as the version (a 6 or 7 nibble under another variant has no timestamp); `nil` instead of an `ArgumentError` for anything that isn't one when passed `false` |
-| `#to_sql_order` `#from_sql_order` | to and from the byte order SQL Server's `uniqueidentifier` sorts by |
+| `#timestamp(raise_on_mismatch: true, layout: :rfc9562)` | the UTC `Time` embedded in an RFC 9562 version 7 UUID held in that layout, in one native call that checks the variant as well as the version (a 7 nibble under another variant has no timestamp, and nor does a v1 or v6 minted elsewhere); `nil` instead of an `ArgumentError` for anything that isn't one when passed `false` |
+| `#to_sql_order` `#from_sql_order` | to and from the layout SQL Server's `uniqueidentifier` sorts by, refusing what doesn't fit it |
 | `==` `eql?` `hash` `<=>` | value equality and byte-order comparison (`Comparable`) |
 
-`#to_sql_order`/`#from_sql_order` convert a version 6 or 7 UUID to and from the byte order SQL
-Server's `uniqueidentifier` needs on the wire to sort by creation order (`#to_sql_order`
-dispatches on the UUID's own version, matching `#timestamp`'s convention) — computed once in
-the native Rust core rather than reimplemented in Ruby, and verified there (and independently
-against the real `System.Data.SqlTypes.SqlGuid` comparator in the C# binding's test suite).
-Same-millisecond v6 UUIDs aren't guaranteed to sort correctly afterward — v6 has no counter,
-so `clock_seq`/`node` (not the timestamp) decide ties, the same pre-existing RFC 9562 v6
-limitation plain order already has. `#from_sql_order` asks the core which version it holds
-(`#version(layout: :sql_server)`, which checks each version's nibble together with its variant
-bits, so a v6 whose random `clock_seq` byte reads as a v7 nibble is still a v6).
+`#to_sql_order`/`#from_sql_order` convert a version 7 UUID to and from the layout SQL Server's
+`uniqueidentifier` needs on the wire to sort by creation order — computed once in the native
+Rust core rather than reimplemented in Ruby, and verified there (and independently against the
+real `System.Data.SqlTypes.SqlGuid` comparator in the C# binding's test suite). The converted
+value is an RFC 9562 version 8: the 8 and the RFC variant sit where SQL Server's text form and
+a .NET `Guid` show them, and the v7's 122 other bits (timestamp, counter, random) fill the rest
+in the order SQL Server compares them. Every v7 converts, and the conversion back is exact.
+Either direction refuses a value of the wrong kind with an `ArgumentError`: anything that isn't
+an RFC 9562 v7 for `#to_sql_order`, anything without the layout's 8 and variant for
+`#from_sql_order`.
 
 ### Layouts
 
 `#version`, `#rfc?` and `#timestamp` take the byte order the value is held in as `layout:`, a
 Symbol: `:rfc9562` (the default, what every other method takes and returns) or `:sql_server`
-(what `#to_sql_order` returns, defined for versions 6 and 7 only). `Uuid::LAYOUTS` lists them.
+(what `#to_sql_order` returns, a version 8 holding a converted v7). `Uuid::LAYOUTS` lists them.
 Anything else is an `ArgumentError`, never a guess. With the default, `#version` and `#rfc?`
 read the value as RFC 9562 order, which looks at the wrong bytes of a SQL-ordered value (one
 from `#to_sql_order`, or a `uniqueidentifier` read back from SQL Server), so pass
 `layout: :sql_server` at every call site that can see one. There is deliberately no
 layout-agnostic check: whoever holds the value knows its order.
 
-`#variant` reads RFC 9562 order only and has no layout form, because in SQL Server order the
-variant sits at a different byte for each version. Don't hand it a SQL-ordered value or a
-`uniqueidentifier` read-back; to validate one, `#rfc?(version, layout: :sql_server)` checks the
-variant where that version puts it.
+`#variant` reads RFC 9562 order only and has no layout form. The SQL Server layout keeps the
+variant in the same place, so a SQL-ordered value reads `:rfc9562` there, but that says nothing
+about whether it holds a converted v7; to validate one, or a `uniqueidentifier` read-back,
+`#rfc?(7, layout: :sql_server)` checks the layout's 8 and variant.
 
 ```ruby
-sql = HyperUuid.new_v6.to_sql_order
-sql.version(layout: :sql_server)   # => 6
-sql.rfc?(6, layout: :sql_server)   # => true
+sql = HyperUuid.new_v7.to_sql_order
+sql.version(layout: :sql_server)   # => 7
+sql.rfc?(7, layout: :sql_server)   # => true
 sql.timestamp(layout: :sql_server) # the same Time as sql.from_sql_order.timestamp
 ```
 
 The bytes alone cannot say which order they are in, so the layout is yours to know: an
-RFC-ordered value can happen to form a SQL-ordered one (a random v4 reads as a SQL-ordered v7
-one time in 16), and `#from_sql_order` then converts it rather than refusing it.
+RFC-ordered value can happen to carry the layout's 8 and variant (a random v4 does one time in
+16), and `#from_sql_order` then converts it rather than refusing it. The same goes the other
+way: a value already in SQL order carries a 7 where `#to_sql_order` looks for the version about
+one time in 16, and is then converted a second time rather than refused.
+
+### Binding to SQL Server
+
+Send `#to_sql_order`'s result as its raw `#bytes`, not as UUID text. SQL Server stores a UUID
+string's first three groups byte-reversed, which loses the creation order
+([details](https://github.com/SkunkWerkx/HyperUuid#sql-server-ordering)); tiny_tds 3.4 and an ActiveRecord `:uuid` attribute both send text. A binary
+literal lands byte for byte:
+
+```ruby
+sql = HyperUuid.new_v7.to_sql_order
+client.execute("INSERT INTO orders (id) VALUES (0x#{sql.bytes.unpack1('H*')})").do
+
+row = client.execute("SELECT CAST(id AS binary(16)) AS id FROM orders").first
+sql = HyperUuid::Uuid.new(row["id"])  # read with layout: :sql_server
+```
+
+In ActiveRecord, map the column as `:binary`, which quotes as `0x…`. Reading needs the `CAST`
+too: tiny_tds returns a `uniqueidentifier` as text with those groups reversed.
 
 ### The version 7 batch limit
 
@@ -109,7 +128,7 @@ mints. A larger count is an `ArgumentError` naming the limit, raised before anyt
 allocated. Every batch is in strictly increasing order: the counter is one process-wide
 sequence, so a batch can straddle the point where it wraps back to 0, and the UUIDs from there
 on carry a timestamp one millisecond later than the one supplied rather than sorting before the
-ones ahead of them. Version 6 has no counter and no such limit.
+ones ahead of them.
 
 That roll-forward orders one batch, not the stream. The next batch or single `new_v7` in the
 same real millisecond starts its counter just past the wrap and carries the supplied timestamp,
@@ -119,23 +138,20 @@ happens at most once per 2²⁶ UUIDs the process mints.
 
 ### Errors
 
-Two exceptions are this gem's own, and both carry the same message on every backend:
+Two exceptions describe a failed call, and both carry the same message on every backend:
 
-- `HyperUuid::TimestampOutOfRangeError` — the time cannot be embedded: past version 7's
-  48-bit millisecond field, past version 6's 60-bit one, or negative (a `Time` before the Unix
-  epoch included).
+- `HyperUuid::TimestampOutOfRangeError` — the time cannot be embedded in a version 7: past
+  its 48-bit millisecond field, or negative (a `Time` before the Unix epoch included).
 - `HyperUuid::RandomSourceError` — the operating system's random source failed.
 
-Through 0.3.0 these were reachable only as `HyperUuid::Runtime::TimestampOutOfRangeError` and
-`HyperUuid::Runtime::RandomSourceError`; those names remain, as aliases of the same classes.
-
 Everything else is a caller bug and raises Ruby's own error for it, checked once in the shared
 doors rather than left to whichever backend is live: a `TypeError` for a time that is not a
 `Time`, an Integer or `nil`, for a count that is not an Integer, for a namespace that is not a
 `Uuid` or a name that is not a `String`, for a version passed to `#rfc?` that is not an
-Integer; an `ArgumentError` for a count outside 0..2³² − 1 (0..`MAX_V7_BATCH` for version 7),
-for a layout other than `:rfc9562`/`:sql_server`, and for a batch too large for the platform to
-address (a 32-bit target such as ruby.wasm).
+Integer; an `ArgumentError` for a count outside 0..`MAX_V7_BATCH` and for a layout other than
+`:rfc9562`/`:sql_server`. Two refusals come from the backend instead, each an `ArgumentError`
+worded the same on both: a batch too large for the platform to address (a 32-bit target such
+as ruby.wasm), and the SQL Server conversions' one refusal, a value of the wrong version.
 
 ### Is the native core there?
 
@@ -143,6 +159,8 @@ address (a 32-bit target such as ruby.wasm).
 raising — for a consumer with a fallback of its own:
 
 ```ruby
+require "securerandom"
+
 id = HyperUuid.available? ? HyperUuid.new_v7.to_s : SecureRandom.uuid
 ```
 
@@ -155,9 +173,9 @@ looked for, or `HyperUuid::NativePlatform::UnsupportedPlatformError` naming the
 
 ## Why not `SecureRandom.uuid`?
 
-`SecureRandom.uuid` gives you a random v4 UUID and `SecureRandom.uuid_v7` a v7 (Ruby 3.3 and later, so every Ruby this gem supports). Ruby's stdlib has no v5 or v6, nothing to read a timestamp back out, no batch form, and no SQL Server ordering. If you need more than that, the choice is really "which gem":
+`SecureRandom.uuid` gives you a random v4 UUID and `SecureRandom.uuid_v7` a v7 (Ruby 3.3 and later, so every Ruby this gem supports). Ruby's stdlib has no v5, nothing to read a timestamp back out, no batch form, and no SQL Server ordering. If you need more than that, the choice is really "which gem":
 
-1. **Full RFC 9562 coverage, one gem, zero extra dependency.** v4/v5/v6/v7 plus batch generation plus `Nil`/`Max`, and nothing added to your `Gemfile.lock` beyond `Fiddle` — Ruby's own bundled FFI layer, not a third-party C extension to compile — and on the precompiled platform gems not even that.
+1. **The RFC 9562 versions new systems use, one gem, zero extra dependency.** v4/v5/v7 plus batch generation plus `Nil`/`Max`, and nothing added to your `Gemfile.lock` beyond `Fiddle` — Ruby's own bundled FFI layer, not a third-party C extension to compile — and on the precompiled platform gems not even that.
 2. **No native-extension compile step.** Third-party UUID gems that go beyond v4 are typically pure Ruby or wrap a C extension compiled at install time; this gem ships its fast path as a prebuilt platform-gem extension and its fallback as a `dlopen`ed prebuilt library — either way, the gem itself compiles nothing at install time ([Install](#install) has the one caveat, which is Fiddle's own).
 3. **Batch generation.** `new_v7_batch(1000)` shares one timestamp capture, one random-bytes fetch, and one counter reservation across the whole batch instead of paying per-item overhead a thousand times over.
 4. **Cross-language consistency.** The same Rust core mints v5 namespace UUIDs for Python, Go, C#, and every other binding in this repo — verified in CI to match Python's own `uuid.uuid5` byte-for-byte. If your system isn't Ruby-only, no Ruby-only gem can offer that.
@@ -166,14 +184,14 @@ The honest trade-off: this gem is native code, not pure Ruby — a precompiled e
 
 ## Bulk generation into bytes
 
-`new_v6_batch_bytes` and `new_v7_batch_bytes` return the batch as one binary `String` of raw RFC 9562-ordered bytes — 16 per UUID — instead of an Array of `Uuid` objects:
+`new_v7_batch_bytes` returns the batch as one binary `String` of raw RFC 9562-ordered bytes — 16 per UUID — instead of an Array of `Uuid` objects:
 
 ```ruby
 bytes = HyperUuid.new_v7_batch_bytes(1000)
 first = bytes[0, 16]        # ready for a BINARY(16) bind parameter
 ```
 
-**About 40x faster than `new_v7_batch`** for a 1000-UUID batch (4.9 µs versus 202 µs). The native call is identical — the difference is that `new_v7_batch` then allocates a `Uuid` object and its byte Strings for every item on top of it. This hands back the bytes the native core already produced, untouched.
+**About 41x faster than `new_v7_batch`** for a 1000-UUID batch (4.9 µs versus 202 µs). The native call is identical — the difference is that `new_v7_batch` then allocates a `Uuid` object and its byte Strings for every item on top of it. This hands back the bytes the native core already produced, untouched.
 
 The catch, and it inverts the advice: **if you need `Uuid` objects, keep using `new_v7_batch`.** Slicing these bytes into objects yourself just relocates the identical allocations into your own code, and measures no better — sometimes worse. Reach for the byte form only when bytes are the destination: a bind parameter, a wire format, a bulk load.
 
@@ -191,9 +209,7 @@ Real numbers, `benchmark-ips` on Ruby 4.0.7, linux-x64 on an Intel Core i9-11900
 |---|---:|---:|
 | `SecureRandom.uuid` | 943,917 | baseline |
 | `HyperUuid.new_v4` | 5,236,000 | **5.5x faster** |
-| `HyperUuid.new_v6` (explicit ms) | 3,811,000 | **4.0x faster** |
 | `HyperUuid.new_v7` (explicit ms) | 3,785,000 | **4.0x faster** |
-| `HyperUuid.new_v6` (current time) | 3,677,000 | **3.9x faster** |
 | `HyperUuid.new_v7` (current time) | 3,574,000 | **3.8x faster** |
 | `HyperUuid.new_v5` | 1,942,000 | 2.1x faster |
 
@@ -201,18 +217,16 @@ A `HyperUuid.new_v4` — real entropy, correct version/variant bits, minted by t
 
 The "current time" rows deserve a footnote, because they will not look like this everywhere. Here they land beside the explicit-ms rows: the only difference between the two is one `Process.clock_gettime(CLOCK_REALTIME)` wall-clock read, and on this machine that read is too cheap to see. On a machine with a slow clock it is the whole story — where a virtualized clock defeats the vDSO fast path the same read costs ~1µs, which puts both current-time rows at parity with `SecureRandom.uuid` while the explicit-ms rows stay well ahead of it. `SecureRandom.uuid` never reads a clock — random v4 is the only thing it does. If your clock is slow and you are minting many, read it once and pass the timestamp, or use the batch doors.
 
-The Fiddle fallback (`HYPERUUID_PURE=1`, and any platform without a prebuilt extension) keeps its own diet — a reused thread-local scratch buffer instead of two GC-finalizer-registering mallocs per call, zero-copy `String` passes for read-only inputs, an unsynchronized fast path past the load mutex — landing at 1.16x slower than `SecureRandom.uuid` for v4 (1.24 µs against 1.07 µs in its own run) and about 1.3x slower for v6/v7, with the same structural story as before: `Fiddle`'s interpreted marshalling is the floor, and the batch doors are how you amortize it.
+The Fiddle fallback (`HYPERUUID_PURE=1`, and any platform without a prebuilt extension) keeps its own diet — a reused thread-local scratch buffer instead of two GC-finalizer-registering mallocs per call, zero-copy `String` passes for read-only inputs, an unsynchronized fast path past the load mutex — landing at 1.16x slower than `SecureRandom.uuid` for v4 (1.24 µs against 1.07 µs in its own run) and about 1.3x slower for v7, with the same structural story as before: `Fiddle`'s interpreted marshalling is the floor, and the batch doors are how you amortize it.
 
 Batch generation still amortizes per-call cost on both backends — one native call for the whole batch:
 
 | Call | i/s (Magnus backend) |
 |---|---:|
-| `new_v6` × 1000 (individual) | 3,761 |
-| `new_v6_batch(1000)` | 4,857 (**1.3x**) |
 | `new_v7` × 1000 (individual) | 3,742 |
 | `new_v7_batch(1000)` | 4,850 (**1.3x**) |
 
-The multiplier is small on this backend for the best reason available: the individual calls are cheap, so there is little waste left to amortize, and what `new_v7_batch` spends its 206 µs on is building a thousand `Uuid` objects — the byte form above does the same native work in 5 µs. On the Fiddle backend, where each call costs 1.4 µs, the same batch is 6.7x the loop. If you need v5/v6/v7, need many at once, or need this Ruby service's IDs to agree byte-for-byte with a Go or Python service's, that's what this gem is for — and now it's the fast option too, not just the capable one.
+The multiplier is small on this backend for the best reason available: the individual calls are cheap, so there is little waste left to amortize, and what `new_v7_batch` spends its 206 µs on (in this table's run; 202 µs in the bytes-versus-objects run above) is building a thousand `Uuid` objects — the byte form above does the same native work in 4.9 µs. On the Fiddle backend, where each call costs 1.4 µs, the same batch is 6.7x the loop. If you need v5/v7, need many at once, or need this Ruby service's IDs to agree byte-for-byte with a Go or Python service's, that's what this gem is for — and now it's the fast option too, not just the capable one.
 
 ## Backends
 
@@ -239,34 +253,42 @@ backend where Ruby threads run the core truly in parallel — each through its o
 buffer, with the core's v7 counter shared and atomic. `spec/hyperuuid_spec.rb`'s "concurrent
 callers" examples run under both.
 
-**Ractors.** Main Ractor only, on every backend: called from another Ractor the doors raise
-`Ractor::UnsafeError`.
+**Ractors.** Main Ractor only, on every backend: called from another Ractor the doors raise a
+`Ractor::Error` (`Ractor::IsolationError`, or `Ractor::UnsafeError`, by door and backend).
 
 ## Verifying provenance
 
-Every gem RubyGems.org serves — the universal fallback, each of the seven precompiled
-platform gems and `hyperuuid-wasm` — carries its own GitHub build-provenance attestation, signed directly by
-this repo's own `release.yml` (the `rubygems-publish` job attests `ruby/pkg/*.gem` right
-before the push), so plain `--repo` verifies any of them:
+Every gem RubyGems.org serves — the universal fallback, each of the seven precompiled platform
+gems and `hyperuuid-wasm` — verifies from the release tag alone: the release attestation,
+signed by this repository's `release.yml` at the tag, names every one of them, with the
+release inventory as its predicate.
+
+```sh
+gem fetch hyperuuid -v <version> --platform <platform>   # or omit --platform for the universal gem
+gh attestation verify hyperuuid-<version>-<platform>.gem --repo SkunkWerkx/HyperUuid \
+  --source-ref refs/tags/v<version> --predicate-type https://github.com/SkunkWerkx/.github/predicates/release/v1
+```
+
+Each gem's build provenance is this repository's too: the `ruby-pack` job attests
+`ruby/pkg/*.gem` as soon as they are built and `rubygems-publish` pushes those preserved
+bytes, so plain `--repo` verifies it:
 
 ```sh
-gem fetch hyperuuid -v X.Y.Z --platform <platform>   # or omit --platform for the universal gem
-gh attestation verify hyperuuid-X.Y.Z-<platform>.gem --repo SkunkWerkx/HyperUuid
+gh attestation verify hyperuuid-<version>-<platform>.gem --repo SkunkWerkx/HyperUuid
 ```
 
-That's the release's second layer of checking, not the only one: before any gem gets built,
-the same job verifies every native binary it packs — the Fiddle libraries, the Magnus
-extensions (one per Ruby ABI per platform), the `wasm32-wasip1` archives — against *their own*
-attestations — those are signed from `SkunkWerkx/.github` by `hyper-build-native.yml` and
-`hyper-build-wasm.yml`, so
-that check needs `--signer-repo SkunkWerkx/.github` added — and refuses to proceed on an
-unverified one. RubyGems.org has no unpublish and no
-duplicate-version overwrite, so this all happens while a bad artifact is still reversible.
-The release run's job summary then re-fetches every gem from the CDN and records
-attested-vs-served digests, turning "rubygems.org stores an upload verbatim" into a
-per-release measurement rather than an assumption — see
-[csharp/README.md's provenance section](../csharp/README.md#native-binary-provenance) for
-more on why `--signer-repo` is needed for some artifacts here and not others.
+That is the release's second layer of checking, not the only one: before any gem is built, the
+same job verifies every native binary it packs — the Fiddle libraries, the Magnus extensions
+(one per Ruby ABI per platform), the `wasm32-wasip1` archives — against *their own* build
+provenance, signed from `SkunkWerkx/.github` by `hyper-build-native.yml` and
+`hyper-build-wasm.yml` (so that check needs `--signer-repo SkunkWerkx/.github` added), and
+refuses to proceed on an unverified one. RubyGems.org has no unpublish and no
+duplicate-version overwrite, so all of this happens while a bad artifact is still reversible,
+and the push itself is a separate dispatch from the preserved bytes. The release run then
+re-fetches every gem from rubygems.org and fails unless each matches the attested bytes
+exactly, turning "rubygems.org stores an upload verbatim" into a per-release check rather than
+an assumption. The root README's [Provenance](../README.md#provenance) section has the whole
+picture.
 
 ## Install
 
@@ -375,7 +397,7 @@ bundle exec rbwasm build --ruby-version 4.0 -o ruby.wasm
 Load `ruby.wasm` with [`@ruby/wasm-wasi`](https://www.npmjs.com/package/@ruby/wasm-wasi)
 (`DefaultRubyVM` in a browser, `RubyVM.instantiateModule` under Node), then
 `require "/bundle/setup"` and `require "hyperuuid"` as anywhere else. `HyperUuid::BACKEND` is
-`:native`: every door, the batch and raw-bytes forms, and `new_v6`/`new_v7` with no argument,
+`:native`: every door, the batch and raw-bytes forms, and `new_v7` with no argument,
 which read the clock through WASI.
 
 - **Ruby 3.4 and 4.0**, one archive each, the same minors the platform gems cover, picked by
@@ -384,6 +406,12 @@ which read the clock through WASI.
 - **No Rust toolchain.** The gem's `extconf.rb` only hands rbwasm the prebuilt archive, and
   rbwasm downloads its own wasi-sdk. The first `rbwasm build` compiles Ruby itself and takes
   15–20 minutes; later builds reuse it.
+- **macOS with Homebrew: limit pkg-config to `openssl@3`.** Run the build as
+  `PKG_CONFIG_LIBDIR="$(brew --prefix openssl@3)/lib/pkgconfig" bundle exec rbwasm build …`.
+  Without it Homebrew's pkg-config files reach into the build twice: its `openssl` is OpenSSL
+  4, which the native Ruby rbwasm builds first does not compile against, and its `libyaml`
+  is a macOS library that psych then links into the wasm interpreter, which fails for Ruby
+  4.0.
 - **Static linking only,** into ruby.wasm's default `wasm32-unknown-wasip1` interpreter.
   rbwasm's dynamic-linking build (a pic target, for the component model) is not supported.
 - **Size.** rbwasm packs every gem's files into the interpreter, the archives included, so the

data/lib/hyperuuid/errors.rb

@@ -1,12 +1,11 @@
 module HyperUuid
   # Raised when the operating system's random source fails while a UUID is being minted —
-  # the one way `new_v4`, `new_v6`, `new_v7` and their batch forms can fail once their
+  # the one way `new_v4`, `new_v7` and its batch forms can fail once their
   # arguments are valid. Carries the same message on every backend.
   class RandomSourceError < StandardError; end
 
-  # Raised when a timestamp cannot be embedded in the UUID being minted: a version 7 value
-  # past RFC 9562's 48-bit millisecond field, a version 6 value past its 60-bit field, or
-  # any negative one (a `Time` before the Unix epoch included). Carries the same message on
-  # every backend.
+  # Raised when a timestamp cannot be embedded in the version 7 UUID being minted: one past
+  # RFC 9562's 48-bit millisecond field, or a negative one (a `Time` before the Unix epoch
+  # included). Carries the same message on every backend.
   class TimestampOutOfRangeError < StandardError; end
 end

data/lib/hyperuuid/runtime.rb

@@ -15,17 +15,9 @@ module HyperUuid
   # A Ruby gem's files are plain files on disk once installed, so native/{rid}/{lib} can be
   # dlopen'd directly, with no extraction step.
   module Runtime
-    # The package's two exceptions live on HyperUuid itself (errors.rb). These are the names
-    # they had through 0.3.0, kept as aliases of the very same classes so a
-    # `rescue HyperUuid::Runtime::TimestampOutOfRangeError` written against an earlier
-    # release still catches.
-    RandomSourceError = HyperUuid::RandomSourceError
-    TimestampOutOfRangeError = HyperUuid::TimestampOutOfRangeError
-
-    # One copy of each out-of-range message for the Fiddle backend and for the
-    # doors' own range check in hyperuuid.rb; the Magnus extension (rust/src/ruby_ext.rs)
-    # carries the same text, and spec/native_backend_spec.rb pins that the two agree.
-    V6_TIMESTAMP_OUT_OF_RANGE = "unix_millis does not fit the 60-bit v6 timestamp field"
+    # One copy of the out-of-range message for the Fiddle backend and for the doors' own
+    # range check in hyperuuid.rb; the Magnus extension (rust/src/ruby_ext.rs) carries the
+    # same text, and spec/native_backend_spec.rb pins that the two agree.
     V7_TIMESTAMP_OUT_OF_RANGE = "unix_millis must fit within the RFC 9562 48-bit field"
 
     # The two batch-size refusals, shared the same way: a version 7 batch past the 26-bit
@@ -36,6 +28,11 @@ module HyperUuid
     V7_BATCH_TOO_LARGE = "a single version 7 batch takes at most 67108864 UUIDs (the 26-bit counter space)"
     BATCH_TOO_LARGE_TO_ADDRESS = "the batch is too large to address on this platform"
 
+    # The SQL Server order conversions' one refusal, in the core's own words (the Magnus
+    # extension raises its SqlOrderError's text): a value that isn't a UUID of the
+    # conversion's version (code 5), an ArgumentError. Every version 7 converts.
+    SQL_ORDER_WRONG_VERSION = "the value is not a UUID of the version this conversion takes"
+
     # The core's v7::MAX_BATCH, which hyperuuid.rb publishes as HyperUuid::MAX_V7_BATCH.
     MAX_V7_BATCH = 1 << 26
 
@@ -65,33 +62,6 @@ module HyperUuid
         out[0, 16]
       end
 
-      def new_v6(unix_millis)
-        out = scratch
-        rc = functions[:new_v6].call(unix_millis, out)
-        case rc
-        when 0 then out[0, 16]
-        when 2 then raise TimestampOutOfRangeError, V6_TIMESTAMP_OUT_OF_RANGE
-        else raise random_source_failure("uuid_new_v6")
-        end
-      end
-
-      def v6_unix_millis(bytes)
-        functions[:v6_unix_millis].call(bytes)
-      end
-
-      def new_v6_batch(count, unix_millis)
-        return "" if count.zero?
-
-        out = buffer(count * 16)
-        rc = functions[:new_v6_batch].call(unix_millis, count, out)
-        case rc
-        when 0 then out[0, count * 16]
-        when 2 then raise TimestampOutOfRangeError, V6_TIMESTAMP_OUT_OF_RANGE
-        when 3 then raise ArgumentError, BATCH_TOO_LARGE_TO_ADDRESS
-        else raise random_source_failure("uuid_new_v6_batch")
-        end
-      end
-
       def new_v7(unix_millis)
         out = scratch
         rc = functions[:new_v7].call(unix_millis, out)
@@ -140,19 +110,16 @@ module HyperUuid
         functions[:is_rfc].call(bytes, version, layout) == 1
       end
 
-      # The Unix ms of an RFC 9562 version 6 or 7 UUID held in +layout+'s order, or nil for
-      # anything else — another version, another variant. One core call; the version it
-      # answers with is not needed above Runtime, so it is dropped here.
+      # The Unix ms of an RFC 9562 version 7 UUID held in +layout+'s order, or nil for
+      # anything else — another version (a version 6 or 1 included), another variant. One
+      # core call; the version it answers with is not needed above Runtime, so it is dropped
+      # here.
       def get_timestamp(bytes, layout)
         out = millis_scratch
         version = functions[:get_timestamp].call(bytes, layout, out)
         version.zero? ? nil : out[0, 8].unpack1("Q")
       end
 
-      def v6_unix_millis_in(bytes, layout)
-        functions[:v6_unix_millis_in].call(bytes, layout)
-      end
-
       def v7_unix_millis_in(bytes, layout)
         functions[:v7_unix_millis_in].call(bytes, layout)
       end
@@ -165,14 +132,6 @@ module HyperUuid
         rewrite(:v7_to_rfc_order, bytes)
       end
 
-      def v6_to_sql_order(bytes)
-        rewrite(:v6_to_sql_order, bytes)
-      end
-
-      def v6_to_rfc_order(bytes)
-        rewrite(:v6_to_rfc_order, bytes)
-      end
-
       # The loaded core's version word, major << 16 | minor << 8 | patch, straight from the
       # library's zero-argument hyperuuid_version export. HyperUuid.native_version unpacks
       # it; like every method here, each backend replaces this one in place.
@@ -253,12 +212,16 @@ module HyperUuid
       end
 
       # The in-place byte-order rewrites are the one shape that must copy in: the native
-      # call genuinely mutates the buffer, and the input String is frozen.
+      # call genuinely mutates the buffer, and the input String is frozen. A refusal leaves
+      # the buffer as it was and raises what the Magnus extension raises for it.
       def rewrite(symbol, bytes)
         buf = scratch
         buf[0, 16] = bytes
-        functions[symbol].call(buf)
-        buf[0, 16]
+        case (rc = functions[symbol].call(buf))
+        when 0 then buf[0, 16]
+        when 5 then raise ArgumentError, SQL_ORDER_WRONG_VERSION
+        else raise "uuid_#{symbol}: unexpected return code #{rc}"
+        end
       end
 
       # Loaded lazily and exactly once, mirroring Java's class initializer / Swift's lazy
@@ -281,21 +244,6 @@ module HyperUuid
             [Fiddle::TYPE_VOIDP, Fiddle::TYPE_VOIDP, Fiddle::TYPE_UINT32_T, Fiddle::TYPE_VOIDP],
             Fiddle::TYPE_INT
           ),
-          new_v6: Fiddle::Function.new(
-            handle["uuid_new_v6"],
-            [Fiddle::TYPE_UINT64_T, Fiddle::TYPE_VOIDP],
-            Fiddle::TYPE_INT
-          ),
-          v6_unix_millis: Fiddle::Function.new(
-            handle["uuid_v6_unix_millis"],
-            [Fiddle::TYPE_VOIDP],
-            Fiddle::TYPE_UINT64_T
-          ),
-          new_v6_batch: Fiddle::Function.new(
-            handle["uuid_new_v6_batch"],
-            [Fiddle::TYPE_UINT64_T, Fiddle::TYPE_UINT32_T, Fiddle::TYPE_VOIDP],
-            Fiddle::TYPE_INT
-          ),
           new_v7: Fiddle::Function.new(
             handle["uuid_new_v7"],
             [Fiddle::TYPE_UINT64_T, Fiddle::TYPE_VOIDP],
@@ -314,22 +262,12 @@ module HyperUuid
           v7_to_sql_order: Fiddle::Function.new(
             handle["uuid_v7_to_sql_order"],
             [Fiddle::TYPE_VOIDP],
-            Fiddle::TYPE_VOID
+            Fiddle::TYPE_INT
           ),
           v7_to_rfc_order: Fiddle::Function.new(
             handle["uuid_v7_to_rfc_order"],
             [Fiddle::TYPE_VOIDP],
-            Fiddle::TYPE_VOID
-          ),
-          v6_to_sql_order: Fiddle::Function.new(
-            handle["uuid_v6_to_sql_order"],
-            [Fiddle::TYPE_VOIDP],
-            Fiddle::TYPE_VOID
-          ),
-          v6_to_rfc_order: Fiddle::Function.new(
-            handle["uuid_v6_to_rfc_order"],
-            [Fiddle::TYPE_VOIDP],
-            Fiddle::TYPE_VOID
+            Fiddle::TYPE_INT
           ),
           version: Fiddle::Function.new(
             handle["uuid_version"],
@@ -347,11 +285,6 @@ module HyperUuid
             [Fiddle::TYPE_VOIDP, Fiddle::TYPE_UINT32_T, Fiddle::TYPE_VOIDP],
             Fiddle::TYPE_UINT32_T
           ),
-          v6_unix_millis_in: Fiddle::Function.new(
-            handle["uuid_v6_unix_millis_in"],
-            [Fiddle::TYPE_VOIDP, Fiddle::TYPE_UINT32_T],
-            Fiddle::TYPE_UINT64_T
-          ),
           v7_unix_millis_in: Fiddle::Function.new(
             handle["uuid_v7_unix_millis_in"],
             [Fiddle::TYPE_VOIDP, Fiddle::TYPE_UINT32_T],

data/lib/hyperuuid/uuid.rb

@@ -40,8 +40,8 @@ module HyperUuid
 
     # The byte orders a Uuid can hold, as the +layout:+ keyword of #version, #rfc? and
     # #timestamp takes them, mapped to the native core's layout codes. +:rfc9562+ is RFC 9562
-    # order, what every other method here takes and returns. +:sql_server+ is the order
-    # #to_sql_order returns, defined for versions 6 and 7 only.
+    # order, what every other method here takes and returns. +:sql_server+ is the layout
+    # #to_sql_order returns, a version 8 that holds a converted version 7.
     LAYOUTS = { rfc9562: 1, sql_server: 2 }.freeze
 
     # The Symbols #variant returns, indexed by the native core's variant code (1-4; 0 is
@@ -66,10 +66,11 @@ module HyperUuid
     #
     # In +:rfc9562+ (the default) it is the version nibble (bits 48-51, the high nibble of
     # octet 6), 0 through 15: Nil reads as 0 and Max as 15. It says nothing about the variant;
-    # #rfc? checks both. In +:sql_server+, the order #to_sql_order returns, it is 6 or 7 for a
-    # SQL-ordered version 6 or 7 UUID and 0 when the bytes don't form one, since no other
-    # version has a SQL Server order. It reads the bytes as given: an RFC-ordered value can
-    # happen to form a SQL-ordered v6 or v7, so the layout is the caller's to know.
+    # #rfc? checks both. In +:sql_server+, the layout #to_sql_order returns, it is the version
+    # the value was converted from, 7, when the bytes carry the layout's version 8 and RFC
+    # variant, and 0 when they don't. It reads the bytes as given: an
+    # RFC-ordered value can happen to carry them (a random v4 does one time in 16), so the
+    # layout is the caller's to know.
     #
     # With the default layout, the value is read as RFC 9562 order. A SQL-ordered value — from
     # #to_sql_order, or a +uniqueidentifier+ read back from SQL Server — needs
@@ -86,19 +87,19 @@ module HyperUuid
     # versions), +:ncs+ (+0xxx+, Nil among them), +:microsoft+ (+110x+) or +:future+ (+111x+,
     # Max among them).
     #
-    # RFC 9562 order only. There is no layout form, because in SQL Server order the variant
-    # sits at a different byte for each version, so don't hand it a SQL-ordered value or a
-    # +uniqueidentifier+ read back from SQL Server. To validate one of those, use
-    # <tt>rfc?(version, layout: :sql_server)</tt>, which checks the variant where that version
-    # puts it.
+    # RFC 9562 order only, with no layout form. The SQL Server layout keeps the variant in the
+    # same place, so a SQL-ordered value reads +:rfc9562+ here, but that says nothing about
+    # which version it holds. To validate one, or a +uniqueidentifier+ read back from SQL
+    # Server, use <tt>rfc?(7, layout: :sql_server)</tt>, which checks the layout's version 8
+    # and variant.
     def variant
       VARIANTS.fetch(Runtime.variant(bytes))
     end
 
     # Whether this is an RFC 9562 UUID of version +version+, read in +layout+'s byte order —
     # the RFC 9562 variant and that version together, the guard to run before trusting a
-    # value's version-specific fields. In +:sql_server+ only 6 and 7 can be true. A version
-    # outside 0-15 is simply false.
+    # value's version-specific fields. In +:sql_server+ +version+ is the version the value was
+    # converted from, so only 7 can be true. A version outside 0-15 is simply false.
     #
     # With the default layout, the value is read as RFC 9562 order. A SQL-ordered value — from
     # #to_sql_order, or a +uniqueidentifier+ read back from SQL Server — needs
@@ -121,17 +122,19 @@ module HyperUuid
     end
     alias_method :to_str, :to_s
 
-    # The UTC timestamp embedded in an RFC 9562 version 6 or 7 UUID, held in +layout+'s byte
-    # order: +:rfc9562+ (the default), or +:sql_server+ for a value #to_sql_order returned. One
-    # native call that checks the variant as well as the version: a 6 or 7 in the version
-    # nibble under any variant but +:rfc9562+ is not a version 6 or 7 UUID, so it has no
-    # timestamp (#rfc? is the same check on its own).
+    # The UTC timestamp embedded in an RFC 9562 version 7 UUID, held in +layout+'s byte order:
+    # +:rfc9562+ (the default), or +:sql_server+ for a value #to_sql_order returned (the
+    # timestamp of the version 7 it was converted from). One native call that checks the
+    # variant as well as the version: a 7 in the version nibble under any variant but
+    # +:rfc9562+ is not a version 7 UUID, so it has no timestamp (#rfc? is the same check on
+    # its own). Every other version has none either, a version 6 or 1 from another generator
+    # included.
     #
-    # Raises by default for anything that isn't an RFC 9562 version 6 or 7 UUID; pass
+    # Raises by default for anything that isn't an RFC 9562 version 7 UUID; pass
     # `raise_on_mismatch: false` to get `nil` back instead — for a caller that doesn't already
     # know (or want to separately check) whether this UUID is time-based.
     #
-    # @raise [ArgumentError] if this isn't an RFC 9562 version 6 or 7 UUID in +layout+ (unless
+    # @raise [ArgumentError] if this isn't an RFC 9562 version 7 UUID in +layout+ (unless
     #   +raise_on_mismatch+ is false), or +layout+ isn't one of LAYOUTS' keys.
     def timestamp(raise_on_mismatch: true, layout: :rfc9562)
       millis = Runtime.get_timestamp(bytes, layout_code(layout))
@@ -141,63 +144,39 @@ module HyperUuid
       raise ArgumentError, timestamp_mismatch(layout)
     end
 
-    # Converts an RFC 9562-ordered version 6 or 7 UUID to the byte order SQL Server's
-    # `uniqueidentifier` needs on the wire to sort by creation order. Dispatches on `version`
-    # the same way #timestamp does.
+    # Converts an RFC 9562 version 7 UUID to the layout SQL Server's `uniqueidentifier` needs
+    # on the wire to sort by creation order: an RFC 9562 version 8 UUID (§5.8, the version for
+    # custom layouts, where §6.11 sends a byte order other than the network one).
     #
     # `System.Data.SqlTypes.SqlGuid` comparison — and therefore T-SQL `ORDER BY` on a
     # `uniqueidentifier` column — doesn't compare a GUID's 16 bytes left to right; it uses a
     # fixed, non-sequential byte significance order (octets 10,11,12,13,14,15,8,9,6,7,4,5,
-    # 0,1,2,3, most significant first). Computed once in the native Rust core and verified
-    # there (and independently, against the real SqlGuid comparator, in this project's C#
-    # test suite); this binding calls the same native functions rather than reimplementing
-    # the byte math.
-    #
-    # For v7, this moves the timestamp and counter — the two fields that determine creation
-    # order — into that comparison's most-significant bytes, and moves the trailing entropy,
-    # which carries no ordering information, into the least-significant ones as one intact
-    # block. For v6, which has no monotonic counter the way v7 does, the only field that
-    # determines creation order is the 60-bit timestamp itself, so that moves into the most
-    # significant bytes instead, with `clock_seq`/`node` (independently random per call, not
-    # a counter, so no ordering value either way) relocated into the rest. v6's much simpler
-    # byte layout needs no bit-level repacking to do this — just whole-octet-group
-    # relocation — unlike v7's, and its version/variant land at different sql-order offsets
-    # as a result (octet 8's top nibble / octet 6's top two bits, not 7/8).
-    #
-    # **v6-specific caveat, unlike v7:** two version 6 UUIDs minted at the same millisecond
-    # have identical timestamp bits, so they aren't guaranteed to sort in creation order any
-    # more than plain RFC order already does — a pre-existing RFC 9562 v6 limitation, not one
-    # this transform introduces.
-    #
-    # Meaningful only for a genuine version 6 or 7 UUID.
+    # 0,1,2,3, most significant first). The layout writes the version nibble 8 at octet 7 and
+    # the RFC variant at octet 8, where SQL Server's text form and a .NET `Guid` show them, and
+    # fills the other 122 bits in that comparison's order: the 48-bit millisecond timestamp,
+    # the 26-bit counter and the 48 random bits as one intact block. A version 7 has exactly
+    # those 122 free bits, so every one converts, and #from_sql_order gives back the exact
+    # original. Computed once in the native Rust core and verified there (and independently,
+    # against the real SqlGuid comparator, in this project's C# test suite); this binding calls
+    # the same native functions rather than reimplementing the bit math.
+    #
+    # @raise [ArgumentError] if this isn't an RFC 9562 version 7 UUID.
     def to_sql_order
-      case version
-      when 7 then self.class.new(Runtime.v7_to_sql_order(bytes), true)
-      when 6 then self.class.new(Runtime.v6_to_sql_order(bytes), true)
-      else raise ArgumentError, "to_sql_order is only defined for version 6 or 7 UUIDs, got version #{version}"
-      end
+      self.class.new(Runtime.v7_to_sql_order(bytes), true)
     end
 
-    # Inverse of #to_sql_order — converts a SQL-Server-ordered version 6 or 7 UUID back to
-    # RFC 9562 order.
-    #
-    # A SQL-ordered value's version sits at a different octet depending on which version
-    # produced it, so this asks the native core which one it is — `version(layout:
-    # :sql_server)`, which checks each version's nibble together with its variant bits and
-    # so never mistakes a v6 whose random `clock_seq` byte happens to read as a v7 nibble.
+    # Inverse of #to_sql_order — converts a SQL-Server-ordered value back to the RFC 9562
+    # version 7 UUID it was converted from, exactly. Refuses a value without the layout's
+    # version 8 and RFC variant, an RFC-ordered version 7 among them.
     #
     # The layout is the caller's to know: bytes alone cannot say which order they are in. A
-    # value that was never SQL-ordered can still read as one, and is then converted rather
-    # than refused (a random RFC-ordered v4 reads as a SQL-ordered v7 one time in 16, since its
+    # value that was never SQL-ordered can still carry the layout's 8 and variant, and is then
+    # converted rather than refused (a random RFC-ordered v4 does one time in 16, since its
     # octet 8 already carries the RFC variant and its octet 7 is random).
     #
-    # @raise [ArgumentError] if this isn't a SQL-ordered version 6 or 7 UUID.
+    # @raise [ArgumentError] if this isn't a SQL-ordered value converted from version 7.
     def from_sql_order
-      case Runtime.version(bytes, LAYOUTS[:sql_server])
-      when 6 then self.class.new(Runtime.v6_to_rfc_order(bytes), true)
-      when 7 then self.class.new(Runtime.v7_to_rfc_order(bytes), true)
-      else raise ArgumentError, "from_sql_order: not a recognized version 6 or 7 SQL-ordered UUID"
-      end
+      self.class.new(Runtime.v7_to_rfc_order(bytes), true)
     end
 
     # Whether +other+ wraps the same 16 raw bytes.
@@ -227,11 +206,11 @@ module HyperUuid
 
     # Why #timestamp found none: the message is worked out only once it is going to be raised.
     def timestamp_mismatch(layout)
-      return "timestamp: not a SQL-ordered version 6 or 7 UUID" if layout == :sql_server
+      return "timestamp: not a SQL-ordered version 7 UUID" if layout == :sql_server
 
       found = version
-      message = "timestamp is only defined for version 6 or 7 UUIDs, got version #{found}"
-      [6, 7].include?(found) ? "#{message} with the #{variant.inspect} variant" : message
+      message = "timestamp is only defined for version 7 UUIDs, got version #{found}"
+      found == 7 ? "#{message} with the #{variant.inspect} variant" : message
     end
 
     # The native core's code for +layout+, the one place a layout is checked: an unknown one

data/lib/hyperuuid.rb

@@ -4,21 +4,22 @@ require_relative "hyperuuid/namespaces"
 require_relative "hyperuuid/native_platform"
 require_relative "hyperuuid/runtime"
 
-# RFC 9562 UUID v4 (random), v5 (deterministic), v6 and v7 (time-sortable) generation from one
-# Rust core, reached through whichever of two backends this install can load: the core
-# linked straight into a Magnus native extension (shipped precompiled in the platform gems),
-# or the native libhyperuuid shared library called through Fiddle (the universal gem bundles
-# one per supported platform, picked by HyperUuid::NativePlatform). No runtime bridge in
-# either, and nothing compiled at install time. HyperUuid::BACKEND names the one that loaded; the selection logic
-# is at the bottom of this file.
+# RFC 9562 UUID v4 (random), v5 (deterministic) and v7 (time-sortable) generation, with a
+# version 8 SQL Server order for v7, from one Rust core, reached through whichever of two
+# backends this install can load: the core linked straight into a Magnus native extension
+# (shipped precompiled in the platform gems), or the native libhyperuuid shared library
+# called through Fiddle (the universal gem bundles one per supported platform, picked by
+# HyperUuid::NativePlatform). No runtime bridge in either, and nothing compiled at install
+# time. HyperUuid::BACKEND names the one that loaded; the selection logic is at the bottom of
+# this file.
 #
 # The doors below — with Uuid, Namespaces and the two exception classes — are the public
 # surface, and are shared by every backend, argument validation included: a caller bug raises
 # the same error whichever backend is live.
 module HyperUuid
-  # This gem's own version — distinct from the RFC 9562 UUID *versions* (v4/v5/v6/v7) the
-  # rest of this module generates.
-  VERSION = "0.8.0"
+  # This gem's own version — distinct from the RFC 9562 UUID *versions* (v4/v5/v7) the rest
+  # of this module generates.
+  VERSION = "1.0.0"
 
   # The widest batch count, and the longest v5 name in bytes, the native ABI carries (a u32).
   # (The millisecond count is a u64; unix_millis_from refuses anything wider.)
@@ -27,8 +28,7 @@ module HyperUuid
 
   # The most UUIDs one version 7 batch (#new_v7_batch, #new_v7_batch_bytes) mints:
   # 67,108,864, the size of the 26-bit counter that orders UUIDs within a millisecond. A larger
-  # count is refused with ArgumentError before anything is allocated. Version 6 has no counter
-  # and no such limit.
+  # count is refused with ArgumentError before anything is allocated.
   #
   # Every batch up to this size is in strictly increasing order: the counter is one
   # process-wide sequence, so a batch can straddle the point where it wraps back to 0, and the
@@ -68,7 +68,7 @@ module HyperUuid
   # Converts +value+ to a Unix-epoch millisecond integer: +nil+ becomes the current time, a
   # +Time+ is converted exactly (via its own Rational seconds, avoiding float rounding), and
   # an Integer millisecond count passes through unchanged. Shared by every
-  # `new_v6`/`new_v7`/batch door below so a caller can pass either a `Time` or a raw
+  # `new_v7`/batch door below so a caller can pass either a `Time` or a raw
   # millisecond count interchangeably.
   #
   # This is also where a caller bug is caught once, for every backend: anything else is a
@@ -102,29 +102,6 @@ module HyperUuid
     count
   end
 
-  # Creates a time-sortable UUID version 6 (RFC 9562 §5.6), a field-compatible reordering of
-  # version 1 for better sort/index locality. Defaults to the current time; pass an explicit
-  # `Time` or Unix-epoch millisecond integer to embed a specific time instead. `clock_seq` and
-  # `node` are randomly generated on every call — unlike version 7, there is no monotonic
-  # counter, so calls within the same millisecond are not guaranteed to sort in creation order.
-  #
-  # @raise [TimestampOutOfRangeError] if the time is negative or past the 60-bit v6 field.
-  # @raise [TypeError] if +unix_millis+ isn't a Time, an Integer or nil.
-  def self.new_v6(unix_millis = nil)
-    Uuid.new(Runtime.new_v6(unix_millis_from(unix_millis, Runtime::V6_TIMESTAMP_OUT_OF_RANGE)), true)
-  end
-
-  # Creates `count` time-sortable version 6 UUIDs sharing one timestamp capture — one FFI call
-  # and one random-bytes fetch instead of `count` of each. Defaults to the current time; pass
-  # an explicit `Time` or Unix-epoch millisecond integer to embed a specific time instead.
-  #
-  # @raise [TypeError, ArgumentError] if +count+ isn't an Integer between 0 and 2**32 - 1.
-  # @raise [TimestampOutOfRangeError] if the time is negative or past the 60-bit v6 field.
-  def self.new_v6_batch(count, unix_millis = nil)
-    bytes = new_v6_batch_bytes(count, unix_millis)
-    Array.new(count) { |i| Uuid.new(bytes[i * 16, 16], true) }
-  end
-
   # Creates a time-sortable UUID version 7 (RFC 9562 §6.2). Defaults to the current time; pass
   # an explicit `Time` or Unix-epoch millisecond integer (non-negative, fitting in 48 bits) to
   # embed a specific time instead.
@@ -184,21 +161,6 @@ module HyperUuid
     Runtime.new_v7_batch(count, unix_millis_from(unix_millis, Runtime::V7_TIMESTAMP_OUT_OF_RANGE))
   end
 
-  # Returns `count` version 6 UUIDs as one binary String of raw RFC 9562-ordered bytes,
-  # 16 per UUID. The version 6 counterpart to #new_v7_batch_bytes, with the same rationale and
-  # the same guidance about when it is the right call.
-  #
-  # clock_seq and node are independently random per item; unlike version 7 there is no
-  # monotonic counter, so items minted in the same millisecond are not guaranteed to sort in
-  # creation order.
-  #
-  # @raise [TypeError, ArgumentError] if +count+ isn't an Integer between 0 and 2**32 - 1.
-  # @raise [TimestampOutOfRangeError] if the time is negative or past the 60-bit v6 field.
-  def self.new_v6_batch_bytes(count, unix_millis = nil)
-    count = batch_count(count)
-    Runtime.new_v6_batch(count, unix_millis_from(unix_millis, Runtime::V6_TIMESTAMP_OUT_OF_RANGE))
-  end
-
   # The version of the native core actually loaded, as "major.minor.patch" — read from the
   # library itself (its `hyperuuid_version` export), not from this gem, so a consumer can
   # prove the core behind the doors is the one this binding was built against (and name the

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: hyperuuid-wasm
 version: !ruby/object:Gem::Version
-  version: 0.8.0
+  version: 1.0.0
 platform: ruby
 authors:
 - Brian Buvinghausen