Best Practices: Release and Versioning
Supported Python Versions
The motorbridge SDK supports the following Python versions:
Version Numbering
The SDK follows Semantic Versioning:
Current source alignment:
Version Categories
Installation Channels
PyPI (Production)
TestPyPI (Pre-release)
Pre-release versions may have breaking changes and are not recommended for production.
Git Installation
Checking Installed Version
Command Line
Programmatically
Upgrade Strategies
Conservative Upgrade
Stay on stable versions, upgrade for bug fixes:
Early Adopter
Test pre-releases in development:
Pinned Versions
For reproducible deployments:
Or with version constraints:
API Stability
Version 0.x (Current)
- API may change between minor versions
- Breaking changes documented in release notes
- Recommended to pin versions
Version 1.0+ (Future)
- Semantic versioning guarantees
- Breaking changes only in major versions
- Deprecation warnings before removal
Changelog
v0.5.0
- Hardened ABI controller and motor handles with per-handle locking while keeping public symbols compatible
- Added Python closed-handle guards so calls after
close() raise CallError instead of passing null handles into the ABI
- Added
CoreController drop-time polling cleanup so background receive workers stop when controllers are dropped
- Split the Python CLI into the
motorbridge.cli package while preserving motorbridge-cli, python -m motorbridge, and legacy flat run arguments
- Improved RobStride scan efficiency, documented valid RobStride
pos-vel arguments, and locked MIT argument encoding with regression tests
v0.3.4
- Accepted RobStride save acknowledgements that return a valid device response instead of only a status frame
- Fixed Damiao in-process
ensure_mode() timeout behavior
- Fixed WS Gateway
id_set transport selection so --transport dm-serial does not try to load PEAK/PCAN on macOS
- Added stricter fmt, clippy, and test coverage for release validation
v0.3.3
- Added unified version reporting: Python
motorbridge.__version__, motorbridge.get_version(), motorbridge-cli -v, and Rust motor_cli -v
- Disabled Python CLI long-option abbreviation so invalid options such as
robstride-write-param --mode save are rejected instead of being misparsed
- Added unified
--store 1 support to Python robstride-write-param and damiao-write-param
- Added Rust CLI RobStride/Damiao parameter write persistence alignment
- Updated RobStride type 22 save to send the official payload and wait for a status ACK
v0.3.2
- Fixed RobStride fault/status handling so fault frames update fault cache without polluting latest kinematic state
- Added Python binding access to the latest vendor fault code
v0.3.1
- Added Python ABI accessors for detailed motor fault state
- Improved RobStride thermal/fault diagnostics around abnormal feedback frames
v0.2.9
- Added RobStride host-id-specific ABI helpers:
motor_handle_robstride_ping_host_id and motor_handle_robstride_get_param_f32_host_id
- Added Python wrappers
robstride_ping_host_id(...) and robstride_get_param_f32_host_id(...)
- Validated RobStride
motor_id / device_id as 1..255 and feedback_id / host_id as 0..255
- Updated Rust and Python RobStride scan to probe each listed
--feedback-ids host ID exactly
- Moved canonical Mintlify docs into the sibling
motorbridge-docs repository
v0.2.5
- Added Python CLI
id-set --vendor robstride for RobStride device ID updates
- Aligned Rust/Python RobStride scan defaults around host ID candidates
0xFD,0xFF,0xFE,0x00,0xAA
v0.2.3
- Refactored ABI FFI layers to reduce duplicated controller/motor dispatch code
- Consolidated vendor parameter FFI entrypoints
- Aligned runtime/control robustness fixes across core, vendor controllers, Python bindings, and websocket gateway
Deprecation Policy
- Announcement: Feature marked as deprecated in release notes
- Warning: Runtime deprecation warning added
- Grace Period: At least one minor version
- Removal: Feature removed in next major/minor version
Release Checklist
For maintainers releasing new versions:
-
Update version:
-
Update changelog:
- Document all changes
- Note breaking changes
-
Tag release:
-
Build package:
-
Upload to TestPyPI:
-
Verify installation:
-
Upload to PyPI:
Important Rules
Never reuse the same package version for a second upload.Once a version is uploaded to PyPI, it cannot be overwritten. Always increment the version number for new uploads.
If Upload Fails
CI/CD Integration
GitHub Actions Example
Next Steps