Publish version 1.0

Crossbeam hasn't changed much in a long time. It may be time to publish 1.0 :)

My opinion is that all crates except for crossbeam-epoch have "peaked" and reached maturity. The thing about crossbeam-epoch is that its API is still not perfect and needs some improvement, mainly around custom collectors. But, even considering that, the API hasn't changed in a very long time, so why not just go for 1.0? If we decide to actually change it in the future, we can bump to 2.0.

I proposed we do the following now:

• Bump minimum required Rust version to 1.36.0 (the one with MaybeUninit).
• Fix CI.
• Decide what to do with Require three epoch advancements for deallocation  #416
• Merge Remove #[allow(unsafe_code)] from select! macro #431
• Delete deprecated Backoff::is_complete().
• Bump all crate versions to 1.0 and publish.

What does everyone think?

[BurntSushi]

Exciting! SGTM. :)

[jonhoo]

Oooh, very excited for this!

The one point I think warrants some discussion is the MSRV policy, which I know is a topic many people have opinions on. As we've seen several times with CI breaking, other crates do not consider MSRV a part of their stability guarantee, so saying just "1.36" is inevitably going to cause us headache down the line. If that line is in the README, we need to commit to it for all of 1.0. Of course, if we don't commit to this, then we're a part of the problem. There isn't a good solution to this at the moment I think, but the least painful path probably lies in not committing to a particular version for the entire time of 1.0.

This has also been discussed in the past in #428 (comment), #458 (comment), and #495 (comment).

My suggestion here is to say something like

Crossbeam supports stable Rust releases going back at least six months, and every time the minimum supported Rust version is increased, a new minor version is released. Currently, the oldest supported version is 1.36.

This is definitely a weakly held opinion, and is mostly motivated by the several issues we have seen over the past months (and years) where CI breaks, or where PRs need to make somewhat awkward workarounds to avoid bumping MSRV (maybe-uninit being an example). Not to mention all the ways in which we don't actually have the stated MSRV when different features are used (like alloc).

@jonhoo Good point, I agree with that. We should stop considering bumping MSRV a breaking change.

[BurntSushi]

Agreed. That's roughly similar to the policy I use in core crates (msrv bumps only in minor versions and be somewhat conservative about it in general). I think six months is a decent spot.

[taiki-e]

I also agreed. (and "six months" sounds reasonable to me.)

Also, I'd propose:

• Adjust Atomic::null()'s cfg to avoid Support dynamically sized types #452 being a breaking change.
• Change std feature to depend on alloc feature (alloc crate is available on 1.36, see Fix no_std build #368 (comment) for why it was previously separated)
• Remove deprecated Error::description impls.

EDIT: I forgot to say, but I'm very excited about this.

[jeehoonkang]

In the same spirit with #452, I think custom allocators should also be integrated into the API. It will greatly improve crossbeam's applicability to, e.g., embedded systems programming. But will surely break backward compatibility. I wish we will make it happen before reaching 1.0.

@jeehoonkang It might take a bit until allocator support is fully fleshed out, but it's not a problem if we publish 2.0 for crossbeam-epoch and consequently for crossbeam as soon as that is merged.

I currently don't have time to help work on that or review PRs. Would you perhaps like to take charge of crossbeam-epoch and keep improving it without being blocked on me?

[caelunshun]

It may be worthwhile to consider any changes to crossbeam-queue—I know that #277 and #338 raised questions on how to structure the API. If more specialized SPSC/MPSC/etc. queues are to be added in the future, that should be taken into account before stabilizing.

Out of curiosity, I assume the plan is to release crossbeam-skiplist at some point after 1.0?

Out of curiosity, I assume the plan is to release crossbeam-skiplist at some point after 1.0?

I'll be honest - I don't have the time to push it over the finish line :( But if anyone is interested in doing that, please go ahead! Really, anyone could do it - it just needs docs and that's all. The implementation is solid and finished.

It may be worthwhile to consider any changes to crossbeam-queue—I know that #277 and #338 raised questions on how to structure the API. If more specialized SPSC/MPSC/etc. queues are to be added in the future, that should be taken into account before stabilizing.

#277 didn't provide benchmark numbers that would warrant radically changing the crossbeam-queue crate, IMO. It would also be unfortunate to block stabilization on that if crossbeam-circbuf could simply be another competing crate.

#338 is yet another thing that is simply overflowing my plate :( But I've been meaning to get back to it. It doesn't need to block stabilization because it can be added to the crate after publishing 1.0 simply as a new feature.

[Thomasdezeeuw]

Related issue about possible breaking changes for 1.0: #256.