Skip to content

Minor tweaks; prepare v0.10.0-rc.9#1736

Merged
dhardy merged 6 commits into
masterfrom
push-quwqmqvwzpnk
Feb 4, 2026
Merged

Minor tweaks; prepare v0.10.0-rc.9#1736
dhardy merged 6 commits into
masterfrom
push-quwqmqvwzpnk

Conversation

@dhardy

@dhardy dhardy commented Feb 4, 2026

Copy link
Copy Markdown
Member

@newpavlov this includes a number of what I think are uncontroversial changes from my other PRs and also bumps versions to allow publishing a new pre-release.

I'm not committing to keeping rand_pcg in this repo but for now this is the easiest approach (I also wouldn't make changes here until after v0.10).

@dhardy
dhardy requested a review from newpavlov February 4, 2026 14:50
run: cargo publish
env:
CARGO_REGISTRY_TOKEN: ${{ steps.auth.outputs.token }}
- name: Publish rand

Copy link
Copy Markdown
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
Copy Markdown
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).

@newpavlov newpavlov Feb 4, 2026

Copy link
Copy Markdown
Member

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
Copy Markdown
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
Copy Markdown
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.

@newpavlov

newpavlov commented Feb 4, 2026

Copy link
Copy Markdown
Member

I'm not committing to keeping rand_pcg in this repo but for now this is the easiest approach (I also wouldn't make changes here until after v0.10).

IMO it would be easier to just move rand_pcg to the RNGs repo, publish v0.10.0 (i.e. a proper release, not RC), and use the published version in the benches crate. Or alternatively, just use a Xoshiro RNG from rand.

@dhardy

dhardy commented Feb 4, 2026

Copy link
Copy Markdown
Member Author

Or alternatively, just use a Xoshiro RNG from rand.

This was the plan. Logistically it's easier to wait until after the release.

@dhardy
dhardy merged commit 72afe1e into master Feb 4, 2026
16 checks passed
@dhardy
dhardy deleted the push-quwqmqvwzpnk branch February 4, 2026 16:31
@dhardy

dhardy commented Feb 4, 2026

Copy link
Copy Markdown
Member Author

I forgot to enable Trusted Publishing for rand_pcg so had to publish that manually. It's enabled now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants