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?

[garbagetrash]

Another year, another new job where I've had to explain that Rust really does have mature complex numbers and we can use it for signal processing and no don't mind that 0.4 tag, its actually quite stable.

So... can you consider releasing a 1.0? This says that your 0.4.3 tag is indicating to users that you are in initial development, and want your users to know that the crates API is not stable... is that really the case? The crate is at least 11 years old according to some of the commits I see, so "initial development" is hard to accept. The change log seems to indicate the only changes in the last 4 years have been updating dependencies, which doesn't sound like an unstable API to me.

If you bumped when this issue was made the feared churn would have all been resolved by now, but if you bump in the next few months maybe any churn can be resolved before this crate is old enough to drive?