Publish version 1.0

[ghost]

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).

[ghost]

@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.

[ghost]

@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?

[ghost]

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.

[ghost]

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.

[polarker]

Should a concurrent hash map be done for 1.0? Using similar algorithms from folly, c++, or java etc.

[jonhoo]

I think it's pretty unlikely that a concurrent hash map will be completed and agreed upon for a 1.0. Not to mention that adding something like that can be done without a breaking change :)

[taiki-e]

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

It's been nearly two years since #256 opened, so some may be outdated, but the five breaking changes mentioned in that issue there are:

1. Change the signature of Select::recv() and Select::send()
2. Use the word "closed" instead of "disconnected"
3. Rename Token
4. Make SendError and RecvError single-variant enums
5. Rename Timeout error variants to Empty/Full

I personally like 1 and 5. (I don't have a strong opinion as to which of the signatures proposed by 1 should be adopted.)
For 2, I don't have a strong opinion, but I'm starting to feel that rename makes sense given that "close" is used in most places except (soft-deprecated) std mpsc. (btw, @stjepang's async-channel crate also uses "close") See #561
For 3, given that mio didn't finally rename it, probably we don't have to do it.
For 4, it does not seem to be a common pattern, so I tend to prefer not to do it.

[taiki-e]

Update - Here is a list of the remaining (breaking) changes I'm aware of:

Open issues

• crossbeam-channel
  • Change the signature of Select::recv and Select::send (Breaking changes before releasing crossbeam-channel 1.0 #256 (comment))
• crossbeam-epoch
  • Custom allocator support (Publish version 1.0 #503 (comment))
    This may be postponed to 2.0.
• crossbeam-utils
  • Should park_timeout report the reason for their return (timeout or unpark)? (Should park_timeout report the reason for their return (timeout or unpark)? #601)

I tend to accept them, but I'm not very clear about what APIs to add.
@jeehoonkang @Vtec234 Any thoughts about these (or some of these) changes?

Changes pending as breaking

They are accepted but blocked because they are breaking changes.

• crossbeam-utils
  • Remove deprecated AtomicCell::compare_and_swap (Deprecate AtomicCell::compare_and_swap #619)
• crossbeam-epoch
  • Seal Pointer trait (Seal traits that only intended to be implemented within the crate that defines them #620)
  • Remove deprecated Atomic::compare_and_set(_weak), CompareAndSetOrdering, CompareAndSetError (Add Atomic::compare_exchange(_weak) and deprecate Atomic::compare_and_set(_weak) #628)

crossbeam-skiplist

There are no plans to publish skiplist as part of crossbeam 1.0.
See #635 for release of skiplist

[jeehoonkang]

• I wish crossbeam-utils becomes 1.0. I think it has a quite stable API.
• I wish crossbeam-epoch doesn't become 1.0 yet. We have many things to resolve, including but not limited to custom allocator, hazard pointer support ([WIP] Mustardwatching epoch- and pointer-based reclamation #221), ... I wish this crate evolves more freely with pre-1.0 versioning.

[taiki-e]

@jeehoonkang

I think it has a quite stable API.

Agreed.
Also, I think crossbeam-queue is probably just as stable. Only one breaking change (#548) has been made since it was published. There are discussions about adding versions optimized for specific use cases like #338, but they are not changes to existing APIs. Personally, I think it makes sense to provide it as another (more experimental) crate for now.

We have many things to resolve, including but not limited to custom allocator, hazard pointer support (#221), ... I wish this crate evolves more freely with pre-1.0 versioning.

Ok! So considering that the stability is different per sub crate, it seems to be better to publish as 1.0 in order from stable sub crates.

For now, I would like to select crossbeam-utils and crossbeam-queue as crates that the first stabilize.
I think crossbeam-channel is also basically stable enough, but it's not clear about select/Select.
I'm not very familiar with crossbeam-deque so I'm not sure about its stability, but considering its main use cases and there are relatively few crates that depend directly on it, we probably don't need to stabilize it in a hurry.
What do you think?

[jeehoonkang]

Actually, I'm planning to propose a large restructuring of crossbeam-queue (and other crates)... :) May I ask if we could decide when to stabilize it after that?

[taiki-e]

@jeehoonkang

crossbeam-queue (and other crates)

Is crossbeam-utils included in "other crates"? (you said it has a quite stable API)
In either case, I'm fine with postponing the stabilization of those crates.

[jeehoonkang]

@taiki-e sorry for being confusing. I think crossbeam-utils is good to go for 1.0, but the others are not.