Skip to content

Release rodbus 1.6.0-M1 (crates.io only)#189

Merged
jadamcrain merged 2 commits into
mainfrom
release-1.6.0-M1
Jul 20, 2026
Merged

Release rodbus 1.6.0-M1 (crates.io only)#189
jadamcrain merged 2 commits into
mainfrom
release-1.6.0-M1

Conversation

@jadamcrain

@jadamcrain jadamcrain commented Jul 20, 2026

Copy link
Copy Markdown
Member

Milestone release publishing only the rodbus Rust crate to crates.io for the non-spawning server task APIs added in #188.

What's in it

  • Full lockstep version bump 1.5.01.6.0-M1 across all crates, the FFI binding build files (CMake/pom/csproj), and the guide (sitedata.json). Cargo.lock regenerated by cargo.
  • CHANGELOG.md entry for the new non-spawning create_tcp_server_task(), create_rtu_server_task(), create_tls_server_task(), and create_tls_server_task_with_authz() APIs.
  • Stop tracking generated CycloneDX SBOMs (*.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 rodbus alone 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, via ffi/rodbus-ffi/src/lib.rs); a lone rodbus bump 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.json files are build artifacts regenerated by cargo-cyclonedx in CI (the packaging job) and local runs — nothing consumes the committed copies. Being versioned, they drifted stale (1.5.0, carrying a colliding third-party lazy_static@1.5.0). This PR git rm --cacheds them and gitignores *.cdx.json.

Not hand-edited

Lockfiles (Cargo.lock, guide/package-lock.json) regenerate themselves; package-lock.json needs no change (its only 1.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:

git checkout main && git pull
cargo publish -p rodbus --dry-run   # verify
cargo publish -p rodbus

No git tag is pushed — that would trigger the full Maven/NuGet/docs pipeline. 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.

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.
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.
@jadamcrain
jadamcrain merged commit 5548c22 into main Jul 20, 2026
30 checks passed
@jadamcrain
jadamcrain deleted the release-1.6.0-M1 branch July 20, 2026 18:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant