Bump num-family to v1.0?

[HEnquist]

The num crates are very important to the entire rust ecosystem, and my experience from using them is that they are very mature. But they are all still at v0.x. Is there anything that prevents bumping them all to v1.0?

[cuviper]

There's nothing much preventing that if we do it without changes, but there's not much benefit either, only perception. It would also cause a lot of churn in the ecosystem to get everyone to move, or else we'd need a semver-trick re-export to make the versions compatible.

[WalterSmuts]

or else we'd need a semver-trick re-export to make the versions compatible.

So this option has no downsides?

[HEnquist]

I was thinking of just bumping the versions to 1.0 and releasing without any other changes. This makes it clear that these crates are indeed stable and mature, and I think this is the main advantage. As a bonus, the versioning gets easier with the "proper" version numbers. The pre-1.0 versioning is a bit clunky IMO.

[Rudxain]

So this option has no downsides?

Note

The following may be slightly wrong, because I don't have enough knowledge, and I'm sleepy

I guess the downside is that every single num* crate would need a separate temporary branch to host the code for the pre 1.0 version, this way both pre/post versions can be kept updated (pre, essentially being a backport). The "nice" thing is that these branches are quite simple because of the re-exports (we can use wildcards for convenience), so all modules and tests can be removed, leaving only lib.rs.

The bad thing is that any non-patch (semver) has to be manually omitted from the backport, to avoid violating semver. This requires turning wildcards into explicit pub use that enumerates every single identifier, except for the one that must remain unchanged (that one is solved by 📋copy-paste macros). The good thing is that we only need to do this once, because every other identifier "left behind" can be extracted manually without converting wildcards.

TLDR: it requires a lot of time and work at the beginning, and many "boilerplate branches" across repos

[Chris--B]

but there's not much benefit either, only perception

I think you're underselling the benefit of perception. Seeing foundational crates across the ecosystem with "pre-release" versions paints a picture of a language that's immature and still changing. If num is still expecting churn, then sure, don't bump to 1.0. But if it's functionally stable and mature, I think there is real value in broadcasting that through the versioning scheme.

Updating sounds like it has one-time costs, but that's inevitable someday unless the plan is to never hit a 1.0... in which case I don't see much use in having versions to begin with.

[Chris--B]

The 500th day anniversary of this issue being opened is next week. We're still at version 0.4. If we had done a 1.0 bump in 2022, most of that ecosystem churn would have resolved by now.

What needs to happen for a 1.0 of the num family of crates?