hubcio opened a new pull request, #3110:
URL: https://github.com/apache/iggy/pull/3110

   0.8.0 rc1 passed both PPMC and IPMC votes, then cargo publish
   revealed the iobuf crate could not reach crates.io: the name
   "iobuf" is already owned by an unrelated v5.8.1 crate, so adding
   a version field would have turned any downstream `cargo add
   iggy_common` into a supply-chain hazard resolving the foreign
   crate transitively.
   
   Publishing the workspace copy under a new name (iggy_iobuf) was
   rejected because it would commit the project to SemVer stability
   on ~485 LoC of refcounted unsafe code with zero tests, zero docs,
   and a latent refcount-underflow UAF masked by debug_assert!.
   
   Move core/iobuf/src/lib.rs verbatim into
   core/binary_protocol/src/consensus/iobuf.rs, delete the standalone
   crate, and update every consumer to import through
   iggy_binary_protocol::consensus::iobuf. The implementation is
   byte-for-byte unchanged; the existing lint debt is suppressed at
   the module declaration and tracked for a 0.9.x cleanup pass.
   
   Also close the SemVer leak:
   iobuf types were reachable through iggy_common's public API via
   FrozenBatchHeader and a `pub use send_messages2::*` wildcard
   re-export. Demote FrozenBatchHeader to pub(crate), drop the
   wildcard (no external consumers relied on it), and seal
   FragmentedBacking so downstream crates cannot implement it and
   pull Frozen<MESSAGE_ALIGN> into their own signatures.
   
   The publish chain drops from 5 crates to 4:
   iggy_binary_protocol -> iggy_common -> iggy -> iggy-cli.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to