update ulid-rs to v3

[walf443]

fake depends on ulid = "1", while ulid is now at 3.0.0 (2.0.0 and 3.0.0 both landed in July 2026). Cargo keeps the two majors in the graph as distinct crates, so impl Dummy<Faker> for Ulid targets a Ulid that is not t
he one an application using current ulid has.

https://github.com/dylanhart/ulid-rs#changelog

Why 3 rather than 2

ulid 2.0.0 and 2.0.1 both landed on 2026-07-11 and 3.0.0 followed on 2026-07-16, so 2.x was the current release for five days. I do not think it is worth targeting: nobody chose it as a resting point, they were passing through.

Being fair to the counter-argument, 2.x is not unused. Current download counts are 2.0.1 at 568k against 3.0.0 at 515k — 2.0.1 is slightly ahead, which is what five extra days of availability buys. Both are small next to 1.2.1 at 23.6M, so the overwhelming majority of users are still on the major fake already supports, and whichever of 2 or 3 you pick, the same set of people has to move.

Given that, 3 seems the better target: it is the current release, it is where new work will land, and supporting both 2 and 3 would mean carrying the public-dependency problem twice.

The implementation looks source-compatible

src/impls/ulid/mod.rs uses Ulid::TIME_BITS, Ulid::RAND_BITS and Ulid::from_parts. All three are present in 3.0.0 with the same signatures, and the body compiles unchanged against it — I checked by building it as a stand
alone function:

pub fn dummy_with_rng<R: RngExt + ?Sized>(rng: &mut R) -> Ulid {
    let time_part: u64 = rng.random_range(0..(1 << Ulid::TIME_BITS));
    let rand_part: u128 = rng.random_range(0..(1 << Ulid::RAND_BITS));
    Ulid::from_parts(time_part, rand_part)
}

So the change may be just the version requirement, though I have not run your test suite against it.

MSRV impact looks like none, and the graph gets smaller

I expected ulid 3 to raise the bar and it does not. It is still edition = "2018" and declares no rust-version. The only meaningful constraint it brings is rand 0.10 (through the default std feature), which is edition = "2024" with rust-version = "1.85" — and fake already depends on rand = "0.10" unconditionally:

[dependencies.rand]
version = "0.10"
features = ["chacha"]

So ulid 3 would add no constraint that is not already there. Please correct me if rust-version = "1.63" in Cargo.toml is tracking something other than the resolvable minimum — from the outside it reads as though the effective floor is already 1.85 via rand.

Staying on ulid 1 also costs something today. An application on current ulid ends up carrying both majors of ulid and both majors of rand, because ulid 1.2.1 pulls rand 0.9:

$ cargo tree -d
rand v0.9.5
rand v0.10.2
rand_core v0.9.5
...
ulid v1.2.1
ulid v3.0.0

Bumping collapses all of that to one ulid and the rand 0.10 that is already required.

The awkward part

Ulid appears in fake's public API through the Dummy impl, so the requirement is a public dependency and moving it is breaking for anyone still on ulid 1.x. That makes this a question about release timing rather than a one-line fix, which is why I am opening an issue rather than a PR.

If it helps, some options as I see them:

• bump to ulid = "3" whenever the next breaking release is due;
• widen to ulid = ">=1, <4", letting the application pick — this compiles for the impl as written, but it makes fake's public API depend on which major resolves, so it may be more trouble than it is worth;
• leave it, and document that the ulid feature targets ulid 1.x.

Happy to send a PR for whichever you prefer.