AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Informational 20 Bitcoin

Re-release without rc suffix

Public commit record

What the developer wrote

Authored by Tobin C. Harding

90/100 · Strong
Re-release without rc suffix

Turns out that the `-rc.0` suffix causes way more problems than it
solves because of how `cargo` resolves the version numbers and what we
intended on using the RC releases for.

In brief

- We wanted to be able to do breaking changes if required
- We wanted to signal that these releases were almost there (TM)
- We wanted to be able to do downstream testing including releasing
downstream crates with the RC releases as part of their public API.

In hindsite we messed up and should have just kept iterating as normal
until we were ready.

Re-release the whole stack without any rc suffix's. However keep
`bitcoin 0.33.0-beta` because we want 0.32.0 to be the latest stable
release and its important that it shows as such on docs.rs

Also, for pre-1.0 crates that had an rc release just jump to the next
version i.e., `io 0.4.0-rc.0` goes to `io 0.5.0`. Just for good
measure.


crate | latest stable | latest RC | with this applied
-----------------------------------------------------------
consensus_encoding 0.0.0 1.0.0-rc.3 0.1.0
units 0.2.0 1.0.0-rc.4 0.3.0
primitives 0.101.0 1.0.0-rc.2 0.102.0
hashes 0.19.0 - 0.20.0
io 0.3.0 0.4.0-rc.0 0.5.0
base58ck 0.3.0 - 0.4.0


bitcoin - 0.33.0-beta.0 to be yanked. Release as 0.33.0-beta

p2p - updated deps, unrelased so no other changes.
internals - not touched (currently 0.5.0)
chacha20_poly1305 - not touched
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit is a routine release-management change for the rust-bitcoin project. It re-releases several crates without the '-rc' (release candidate) suffix in their version numbers and updates internal dependency version requirements accordingly. There are no code logic changes, bug fixes, or security patches in the diff—only version numbers, lock files, changelogs, and README text.

Recommended action

No security action required. Treat as a normal release/versioning update. Downstream users should verify that the new pre-1.0 version numbers and relaxed dependency constraints are compatible with their own Cargo version requirements, but this is a dependency-management concern, not a security issue.

Security signals we found

No strong security signals were identified.

Risk score

Why this scored 20/100

Our methodology →
Potential impact 0/30
Exploitability 0/25
Stealth signal 0/15
Affected reach 5/15
Confidence 10/10
Evidence quality 5/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.