How should release/1.0.1 fixes be brought back to main?

[jkossis]

@overtrue @houseme — what is the intended process for bringing fixes from release/1.0.1 back to main?

I noticed #8290 was retargeted from main to release/1.0.1 and merged there. The documented release workflow describes landing fixes on main first, then backporting them. Is release-first development intentional during the 1.0.1 preview cycle?

At the October 1 snapshot (main: 50e6c907f; release: c04d566b2), release has 22 commits absent from main's history, while main has 5 absent from release. These are history counts, not 22 distinct missing fixes: some changes overlap or were integrated differently. Branch comparison.

Comparing the final source trees, these notable changes remain absent from main:

Release PRs	Changes
#8108	Lifecycle-expiration usage accounting and upgrade-test fixture corrections
#8273	Historical usage-counter recovery with generation fencing
#8258, #8293	Scanner pause-backlog diagnostics and recovery verification
#8274	Distinguishing cumulative allocator counters from live memory
#8275	Checkpoint takeover and repair-dispatch regression coverage
#8290	Bucket-operation queuing
#8290, CI commit 537c15277	Rust 1.99 compatibility: deprecated atomic APIs, needless closure borrows, recursive boxed futures, and removal of the unused recursion dependency
Commit b54b32b8a	Cargo Deny correction: replace yanked yoke-derive 0.8.3 with 0.8.4
#8287	UploadPart memory diagnostic harness and warnings for ignored cache settings

There are also dependency updates and smaller test fixes. Conversely, main's multipart-copy/buffering changes in #8288 differ from the release implementation, so a blanket cherry-pick would need reconciliation.

Main-targeted #8292 is intentionally limited to the scanner checkpoint fix and its regression test. The CI compatibility and yanked-dependency corrections are excluded from that PR and listed above for separate forward-porting to main. Its original Rust 1.99 lint failures matched main's failures. The lifecycle and historical-usage changes are also particularly relevant to our storage qualification.

Would you prefer targeted forward-port PRs, or is a release-to-main reconciliation already planned? A tracking issue for the remaining differences would help contributors avoid duplicate work and keep these fixes from being lost in subsequent releases.

[jkossis]

Closing this as resolved. #8314 brought the 1.0.1 release changes back into main, and #8301 addressed the Rust 1.99 compiler corrections. After checking the current source differences, none of the specific missing fixes listed above remains outstanding in main. Thanks @overtrue and @houseme for the reconciliation.

The branches still differ because main contains newer work. Publishing a numbered release or preview containing #8292 is a separate follow-up tracked in #8113.