Deprecate in favor of UUIDv7

[booch]

I just read about UUIDv7. It's a proposed IETF standard, in "last call". Other than the base32 encoding, it's got everything we want from ULID. UUIDv7 will be more widely accepted and available to developers.

I propose that we declare victory, and allow the UUID spec to take over the effort from here on.

[booch]

See #85 for some additional discussion.

[peterbourgon]

ULIDv7 has weaker rules for each part of the ID, and sacrifices 4 bits of entropy to a static version identifier. It's different enough that I don't think it makes sense to "deprecate" ULIDs.

[arokettu]

4 bits

6 bits. Still, UUIDv7 solves some ULID issues like predictability of the monotonic factory, and UUIDs being better supported in databases in general

[peterbourgon]

ULIDs don't have predictable monotonicity unless generated as such, and database support is a red herring 🤷

[arokettu]

ULIDs don't have predictable monotonicity unless generated as such

ULID spec is unclear about that (#80) but some implementations are monotonic by default in spec-described unsafe way (like symfony/uid)

database support is a red herring 🤷

It's not, it's the reason I'm no longer using ULIDs for new projects

[peterbourgon]

ULIDs and UUIDs are represented in databases identically: as 128bit numbers both.

Whether or not IDs have monotonic entropy is opt-in by the producer. And whether or not predictable monotonicity is a problem is a function of use case (it is not always a problem).

[arokettu]

ULIDs and UUIDs are represented in databases identically: as 128bit numbers both.

If stored in binary, you can't manually query a ULID given its string. With UUID even without db support you can simply remove dashes and query as a raw hex

[fabiolimace]

You all probably already know, but just in case, RFC 9562 was published a few days ago (May 7, 2024). RFC 4122 is obsolete and UUIDv7 is now official.

https://www.rfc-editor.org/rfc/rfc9562
https://datatracker.ietf.org/doc/rfc9562