Release rodbus 1.6.0-M1 (crates.io only)#189
Merged
Merged
Conversation
Milestone to publish only the `rodbus` crate to crates.io for the non-spawning server task APIs (#188). There are no FFI changes, so this milestone is not pushed to Maven/NuGet/docs. Full lockstep version bump 1.5.0 -> 1.6.0-M1 across all crates, FFI binding build files, and the guide. The lockstep bump is required even for a crates.io-only publish: the FFI layer asserts the generated bindings' expected version (rodbus-schema, ffi/rodbus-schema/src/lib.rs) against the native library's runtime version (rodbus::VERSION, via ffi/rodbus-ffi/src/lib.rs), so bumping rodbus alone fails the binding tests in CI. Deliberately NOT bumped: - Lockfiles (Cargo.lock, guide/package-lock.json) regenerate themselves. - SBOM *.cdx.json snapshots are left at 1.5.0 (they carry a colliding lazy_static@1.5.0, don't affect CI or the crates.io publish, and are regenerated at the next tagged release). Release process: this does NOT use the tag-driven pipeline (a tag fires all release jobs across every ecosystem). After merge, publish manually from main with `cargo publish -p rodbus`; no git tag is pushed. Binding versions therefore read 1.6.0-M1 in source but stay published at 1.5.0 until the 1.6.0 final re-syncs everything.
jadamcrain
force-pushed
the
release-1.6.0-M1
branch
from
July 20, 2026 17:40
9159fce to
a5e1fdc
Compare
The *.cdx.json files are build artifacts regenerated by cargo-cyclonedx during CI (the packaging job) and local runs; nothing consumes the committed copies as input. Being under version control, they drifted stale (left at 1.5.0, carrying a colliding lazy_static@1.5.0) and added noise to release bumps. Remove them from the index and gitignore the pattern so they stay out.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Milestone release publishing only the
rodbusRust crate to crates.io for the non-spawning server task APIs added in #188.What's in it
1.5.0→1.6.0-M1across all crates, the FFI binding build files (CMake/pom/csproj), and the guide (sitedata.json).Cargo.lockregenerated bycargo.CHANGELOG.mdentry for the new non-spawningcreate_tcp_server_task(),create_rtu_server_task(),create_tls_server_task(), andcreate_tls_server_task_with_authz()APIs.*.cdx.json) — see below.Why the full bump for a crates.io-only release
The change is pure Rust with no FFI changes, but bumping
rodbusalone fails CI. The FFI layer asserts the generated bindings' expected version (rodbus-schema,ffi/rodbus-schema/src/lib.rs) against the native library's runtime version (rodbus::VERSION, viaffi/rodbus-ffi/src/lib.rs); a lonerodbusbump makes those disagree and aborts the binding tests. So every crate moves together to keep the versions internally consistent.SBOM cleanup
The 8 committed
*.cdx.jsonfiles are build artifacts regenerated bycargo-cyclonedxin CI (the packaging job) and local runs — nothing consumes the committed copies. Being versioned, they drifted stale (1.5.0, carrying a colliding third-partylazy_static@1.5.0). This PRgit rm --cacheds them and gitignores*.cdx.json.Not hand-edited
Lockfiles (
Cargo.lock,guide/package-lock.json) regenerate themselves;package-lock.jsonneeds no change (its only1.5.0s are unrelated npm deps).Release process (differs from RELEASING.md)
This does not use the tag-driven pipeline (a tag fires all release jobs across every ecosystem). After merge, publish manually from
main:No git tag is pushed — that would trigger the full Maven/NuGet/docs pipeline. Binding versions therefore read
1.6.0-M1in source but stay published at1.5.0until the1.6.0final re-syncs everything.