Repository navigation
Add deprecation rules to automatic bump process & CONTRIBUTING.md #1981
Description
#1971 marks proposal_txid_is_stable as #[deprecated(since = "1.3.0")] before we know which release it ships in (comment). A PR should write a placeholder and the bump script should fill in the version, so these can't be forgotten or end up wrong. rust-bitcoin does this with since = "TBD" (CONTRIBUTING.md).
TBD itself is a poor fit. rustc reads it as "deprecated in a future version" and only warns under deprecated_in_future, which is allow-by-default, so nobody calling the item hears about it until the release. Other strings like "Unreleased" do warn, but clippy's deprecated_semver lint rejects them. A pre-release version passes clippy and rustc warns on it as usual, so I'd use 0.0.0-unreleased.
Proposal:
- New deprecations use
#[deprecated(since = "0.0.0-unreleased", note = "...")]. - payjoin-ffi can't use the attribute, since UniFFI doesn't carry deprecations into the bindings (mozilla/uniffi-rs#1219). Its doc comments say
Deprecated since <crate> 0.0.0-unreleased, naming the crate whose release deprecates the item (usuallypayjoin). (Although sometimes there's a chance to delete things from the api out of cadence withpayjoin) bump.sh <crate> <version>replaces the placeholder in<crate>/srcandsince <crate> 0.0.0-unreleasedinpayjoin-ffi/src, next to where it renames the changelog's Unreleased section (bump.sh#L154-L174).check-invariants.shfails if a bumped crate still has a placeholder, the same way it checks the changelog (check-invariants.sh#L43-L44).- The Changelog section of
.github/CONTRIBUTING.mddocuments the placeholder. It currently says the release PR renames the heading "and nothing else".
Activity
Christopherdominic commentedon Oct 19, 2026
@DanGould I'd like to help finish this if there is remaining work. Current
masteralready hasfill_unreleased()incontrib/release/bump.sh, a leftover-placeholder check incheck-invariants.sh, and a Deprecations section in.github/CONTRIBUTING.md.I noticed two details worth confirming before proposing a patch:
payjoin-ffibump resolves named crate versions in its own doc comments. The issue originally suggested updating bindings comments during the named crate's bump. I'd follow the currently documented behavior unless you want that timing changed.For an agreed follow-up, I'd verify Rust attribute replacement, named-crate prose replacement, and rejection of leftover placeholders using disposable release-script fixtures, and run the relevant shell/documentation checks.
Is the current timing intentional, and would a small documentation correction close the remaining scope, or is the implementation already considered complete?
AI disclosure: This comment was drafted with OpenAI Codex assistance.