Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 7 additions & 1 deletion .github/workflows/release.yml
Original file line number Diff line number Diff line change
Expand Up @@ -14,6 +14,12 @@ jobs:
- uses: actions/checkout@v6
- uses: rust-lang/crates-io-auth-action@v1
id: auth
- run: cargo publish
- name: Publish rand_pcg
working-directory: ./rand_pcg
run: cargo publish
env:
CARGO_REGISTRY_TOKEN: ${{ steps.auth.outputs.token }}
- name: Publish rand
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this change is needed. Just publish rand_pcg manually for now. For a multi-crate repository you should use a more involved config, e.g. see one from RustCrypto/traits.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That requires a lot of distinct tags, and potentially that they are pushed in the right order.

This is simpler and works fine provided that all crates are released simultaneously under a single tag (good enough in that case, though I also publish a few patches by hand).

Copy link
Member

@newpavlov newpavlov Feb 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

potentially that they are pushed in the right order.

No, the tag order does not matter. The linked config works fine when you push several release tags to one commit simultaneously. The workflow is triggered separately for each pushed tag.

released simultaneously under a single tag

IMO it's a pretty bad restriction and you should use different tags for each crate release. Either way, I do not insist on the suggested approach, though I most certainly would not use your config in RustCrypto repositories.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, the tag order does not matter.

It would if the crates have any inter-depenencies... unless you just re-run the failures?

IMO it's a pretty bad restriction

It is, and is insufficient if all publishing must be done using Trusted Publishing.

On the other hand, RustCrypto/traits has 435 tags. I thought this repo was bad enough.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would if the crates have any inter-depenencies

Well, obviously if one crates depends on another inside the repo and we are doing breaking releases, crate releases should be properly sequenced and use different commits. But most repositories contain decoupled crates similarly to the RNGs repo and patch releases are more frequent of a crate than sweeping breaking release cycles.

On the other hand, RustCrypto/traits has 435 tags.

A significant number of those is caused by the recent unfortunate explosion of RCs (in hindsight we should've been more conservative with those). Since the tags have predictable structure of crate-name-vX.Y.Z they are easy to search and it's trivial to find exact commit for a crate release.

Either way, the current config is a complete non-starter if crates in repository could be released independently from each other. Arguably, it applies to the rand repo as well. I doubt you want to release new version of rand_pcg on a patch release of `rand. and vice versa.

run: cargo publish
env:
CARGO_REGISTRY_TOKEN: ${{ steps.auth.outputs.token }}
4 changes: 2 additions & 2 deletions Cargo.lock

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

4 changes: 2 additions & 2 deletions Cargo.toml
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
[package]
name = "rand"
version = "0.10.0-rc.8"
version = "0.10.0-rc.9"
authors = ["The Rand Project Developers", "The Rust Project Developers"]
license = "MIT OR Apache-2.0"
readme = "README.md"
Expand Down Expand Up @@ -75,7 +75,7 @@ chacha20 = { version = "0.10.0-rc.10", default-features = false, features = ["rn
getrandom = { version = "0.4.0-rc.1", optional = true }

[dev-dependencies]
rand_pcg = { path = "rand_pcg", version = "0.10.0-rc.1" }
rand_pcg = { path = "rand_pcg", version = "0.10.0-rc.9" }
# Only to test serde
postcard = {version = "1.1.3", default-features = false, features = ["alloc"]}
rayon = "1.7"
Expand Down
6 changes: 3 additions & 3 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -88,11 +88,11 @@ Rand supports limited functionality in `no_std` mode (enabled via
unavailable (unless `sys_rng` is enabled), large parts of `seq` are
unavailable (unless `alloc` is enabled), and `ThreadRng` is unavailable.

## Portability and platform support
## Portability

Many (but not all) algorithms are intended to have reproducible output. Read more in the book: [Portability](https://rust-random.github.io/book/portability.html).
### Reproducibility

The Rand library supports a variety of CPU architectures. Platform integration is outsourced to [getrandom].
Achieving reproducible results requires not only deterministic algorithms with fixed inputs but also a commitment to stability of algorithms and some platform-specific considerations. A subset of `rand` does aim to support reproducibility; read more about this in the book: [Portability](https://rust-random.github.io/book/portability.html).

### WebAssembly support

Expand Down
1 change: 1 addition & 0 deletions rand_pcg/CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,6 +7,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
## [Unreleased]
### Changes
- Use Edition 2024 and MSRV 1.85 (#1653)
- Update to `rand_core` v0.10.0 (#1729)
- Remove feature `os_rng` (#1674)
- Use `postcard` instead of `bincode` to test the serde feature (#1693)

Expand Down
2 changes: 1 addition & 1 deletion rand_pcg/Cargo.toml
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
[package]
name = "rand_pcg"
version = "0.10.0-rc.7"
version = "0.10.0-rc.9"
authors = ["The Rand Project Developers"]
license = "MIT OR Apache-2.0"
readme = "README.md"
Expand Down
3 changes: 1 addition & 2 deletions src/distr/bernoulli.rs
Original file line number Diff line number Diff line change
Expand Up @@ -90,8 +90,7 @@ impl fmt::Display for BernoulliError {
}
}

#[cfg(feature = "std")]
impl std::error::Error for BernoulliError {}
impl core::error::Error for BernoulliError {}

impl Bernoulli {
/// Construct a new `Bernoulli` with the given probability of success `p`.
Expand Down
3 changes: 1 addition & 2 deletions src/distr/slice.rs
Original file line number Diff line number Diff line change
Expand Up @@ -116,8 +116,7 @@ impl core::fmt::Display for Empty {
}
}

#[cfg(feature = "std")]
impl std::error::Error for Empty {}
impl core::error::Error for Empty {}

#[cfg(feature = "alloc")]
impl super::SampleString for Choose<'_, char> {
Expand Down
3 changes: 1 addition & 2 deletions src/distr/uniform.rs
Original file line number Diff line number Diff line change
Expand Up @@ -136,8 +136,7 @@ impl fmt::Display for Error {
}
}

#[cfg(feature = "std")]
impl std::error::Error for Error {}
impl core::error::Error for Error {}

#[cfg(feature = "serde")]
use serde::{Deserialize, Serialize};
Expand Down
3 changes: 1 addition & 2 deletions src/distr/weighted/mod.rs
Original file line number Diff line number Diff line change
Expand Up @@ -100,8 +100,7 @@ pub enum Error {
Overflow,
}

#[cfg(feature = "std")]
impl std::error::Error for Error {}
impl core::error::Error for Error {}

impl fmt::Display for Error {
fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
Expand Down
4 changes: 2 additions & 2 deletions src/rng.rs
Original file line number Diff line number Diff line change
Expand Up @@ -34,8 +34,8 @@ use rand_core::Rng;
/// - Only `Rng` is dyn safe, supporting `&mut dyn Rng` and `R: Rng + ?Sized`.
///
/// An alternative pattern is possible: `fn foo<R: Rng>(rng: R)`. This has some
/// trade-offs. It allows the argument to be consumed directly without a `&mut`
/// (which is how `from_rng(rand::rng())` works); also it still works directly
/// trade-offs. It allows the argument to be consumed directly without a `&mut`;
/// also it still works directly
/// on references (including type-erased references). Unfortunately within the
/// function `foo` it is not known whether `rng` is a reference type or not,
/// hence many uses of `rng` require an extra reference, either explicitly
Expand Down