Release and Versioning

Release and versioning practices for bijux-cli require command-contract stability checks, explicit compatibility review, and reproducible build identity.

Visual Summary

flowchart LR
    candidate["release candidate commit"] --> tests["routing integration docs checks"]
    tests --> contracts["contract and compatibility review"]
    contracts --> tag["tag and release build"]
    tag --> publish["publish artifacts and docs"]

Release Requirements

• green CLI routing, integration, and architecture suites
• updated docs for any command-surface or output-contract changes
• compatibility notes for parser, route, or contract shape updates
• validated runtime version identity in release outputs

Code Anchors

• crates/bijux-cli/build.rs
• crates/bijux-cli/src/shared/version.rs
• crates/bijux-cli/src/api/version.rs
• crates/bijux-cli/tests/architecture/ownership/release_tree_contracts.rs
• makes/docs.mk

Versioning Rules

• treat output and command grammar changes as versioning-significant
• keep semver and release tags aligned with shipped contract behavior
• avoid undocumented behavior changes between patch releases

Current Release Line

• release target: v0.3.4
• published Rust crate: bijux-cli
• published Python package: bijux-cli
• DAG crates remain internal until the coordinated v0.4.0 release line.

Next Reads

• Compatibility Commitments
• Definition of Done
• Change Validation