Tracking issue: release 1.0.0 that includes critical-section support

[taiki-e]

I said in past:

Even if the library's API did not have the CS API, I believe CS would always be considered a public dependency of the library, since updating the CS version or removing CS impls or dependency on CS could break downstream builds.

So, if both portable-atomic 0.3 and portable-atomic 1 support CS (critical-section), updating from portable-atomic 0.3 to portable-atomic 1 may need to be considered a breaking change because it changes the version of the portable-atomic that needs to enable the CS feature in downstream.

This can be addressed by releasing the first portable-atomic with CS support as portable-atomic 1 and never releasing major version 2¹. The portable-atomic's API is stable enough that no changes should be necessary except for the removal of the outline-atomics feature that is no longer used.

TODO

• merge Add Cargo feature to use critical-section. #51; done
• remove the outline-atomics feature that is no longer used; done in fb5bc25
• (adjust docs) aed4e17...a6b3b95

Is there anything else you think is needed for this release?

ETA: I think I can finish this during this weekend.

Footnotes

1. Even if critical-section 2.0 is released, it can be supported with a feature like critical-section2. ↩

[notgull]

How will this be related to a potential release of portable-atomic-util, if any?

We may also want to add a general purpose Atomic<T> type, similar to crossbeam's AtomicCell (maybe better for portable-atomic-util?) #1

I think this crate is in a good state as-is.

[taiki-e]

How will this be related to a potential release of portable-atomic-util, if any?

Good point. As for portable-atomic-util, I would like to give it a different version number than the main portable-atomic crate, as said in #43. i.e., the portable-atomic will be 1.0, but the portable-atomic-util will be released as 0.1. (It is a bug in our release infrastructure that both crates currently use the same version number, and I would like to release portable-atomic-util 0.1 once that is fixed.)

We may also want to add a general purpose Atomic<T> type, similar to crossbeam's AtomicCell (maybe better for portable-atomic-util?) #1

Yeah, as for generic Atomic<T>, I think it would make sense to add it to the portable-atomic-util.
(Without AtomicMaybeUninit it cannot be implemented without limitations or potential UB. And it is not yet clear to me what the best API is to minimize that limitation as much as possible.)

[taiki-e]

Published:

• https://crates.io/crates/portable-atomic/1.0.0
• https://crates.io/crates/portable-atomic-util/0.1.0