Hi @sccg, apologies about the confusion surrounding this. Better documentation around the version numbers for our packages is something we’ll work on. I’ll go back and add release tags to Github for past important versions, and begin adding tags for new releases going forward.
For Stretch Body and Stretch Body Tools, we have release candidate PRs that serve as a way to document all of the features and bugfixes that go into that release. They are:
- 0.1.0: adds support for end-effectors to be “pluggable” in Stretch Body (the actual code for different end-effectors lives in a separate repo called Stretch Tool Share)
- 0.1.4: new URDF visualization tool, added tutorial about collision management
- 0.1.10: adds Jupyter notebook tutorials, adds warnings for high sync rates
- 0.1.11: gives Stretch Body the ability to interface with different firmware protocols
- upcoming 0.2.0: support for waypoint trajectories, which are used in our ROS2 drivers to support MoveIt2
In addition to these release candidate PRs, we’ll add Github release tags and a changelog to docs.hello-robot.com that make it clear what features ship with a new version.
Here’s some more details on how we release software. All of our Python packages are released on PyPi using the “semver” versioning scheme. This means the numbers are MAJOR.MINOR.PATCH, where PATCH is incremented for bugfixes, MINOR is incremented for new functionality, and MAJOR would be incremented for architectural or non-backwards compatible changes. Stretch Body is currently at 0.1.13, and we’ve tried to be consistently backwards compatible (the only exception is noted in Comments about Collision Avoidance - #4 by aedsinger). We began writing tests a few months back to help us ensure that we weren’t introducing regressions with new features. This means that even the earliest robots should be able to upgrade with no issues (and please let us know if you do run into any issues; happy to help resolve them). Let me know if you have any questions.