Repose 0.7: one name

Today we're releasing Repose 0.7. The crates now carry the project's name: the umbrella crate is repose, and every component is repose-<name>. The code has moved to github.com/ReposeRobotics/repose, and the versioning rules are now written down.

This is a breaking release in name only. No behaviour changed, no payload changed and no RON config key changed. If you depend on Repose today, upgrading means changing a few lines of Cargo.toml and some use paths.

Why the rename

Repose started as a set of Copper components called cu-moveit, and its crates followed Copper's cu- naming convention. Since then it has grown into a manipulation stack of its own, with seven motion planners, trajectory timing, a joint controller and a MuJoCo bridge, and it now has its own name. Crate names are what you type in every Cargo.toml and use line, so they should say what you are depending on. Doing it before 1.0, while nothing is on crates.io yet, keeps the cost to one search-and-replace.

What changed

The umbrella crate cu-repose is now simply repose, and every component crate swapped its cu- prefix for repose-:

Rust paths follow the crate names, so cu_kinematics::… becomes repose_kinematics::… and cu_repose::… becomes repose::…. The same goes for task types in RON configs, which name their crate.

What stays the same

• Copper's own crates. cu29, cu-spatial-payloads and the rest of Copper keep their names. Only Repose's crates were renamed.
• Type names. Types keep their Cu prefix: CuKinematicChain, CuJointPlanner, CuJointRrtStarTask and so on. They follow Copper's convention for components, and renaming them would have broken every program for no gain.
• Behaviour and data. No payload encoding, config key, unit or default changed. Logs recorded with 0.6 describe the same messages.

Upgrading

First, point your dependency at the new repository and tag:

# before
cu-repose = { git = "https://github.com/DavidSeyserGit/cu-moveit", tag = "v0.6.0" }

# after
repose = { git = "https://github.com/ReposeRobotics/repose", tag = "v0.7.0" }

Then rename the paths in your code:

// before
use cu_repose::kinematics::{CuIkParams, igus_rebel_chain};

// after
use repose::kinematics::{CuIkParams, igus_rebel_chain};

And the task types in your RON configs:

// before
type: "cu_joint_rrt_star::CuJointRrtStarTask<6>",

// after
type: "repose_joint_rrt_star::CuJointRrtStarTask<6>",

That's the whole migration. A search-and-replace from cu_ to repose_ over your own crate names gets you most of the way; just leave Copper's cu29 and cu_spatial_payloads alone.

How versions work from now on

Alongside the rename, 0.7 writes down the versioning rules that releases already followed, so you can rely on them.

One version for everything. Every crate in the workspace shares one version, and releases are tagged vX.Y.Z on the whole repository. "Repose 0.7" means every repose-* crate at 0.7.x, and everything in one tag works together. There are no per-crate versions to line up.

Minor may break, patch never does. Before 1.0, a minor bump such as 0.7 → 0.8 may break things, and a patch release never does. "Break" covers more than the Rust API. A change counts as breaking if it touches any of these:

• the public Rust API: renamed or removed items, changed signatures, new trait requirements;
• payload encoding: any change to the layout of a payload Copper logs, since that breaks recorded logs and replay even when the code looks the same;
• RON configuration: renamed, removed or reinterpreted keys, or changed units and defaults;
• the Copper (cu29) minor version;
• the minimum supported Rust version.

Compatibility at a glance. The README keeps a table of which Copper version and which Rust version each Repose release needs:

One changelog. Release notes used to live in separate files per release. They are now collected in a single CHANGELOG.md, and every user-visible change is recorded under "Unreleased" as it lands. The full policy is in docs/versioning.md.

Still no crates.io. Until 1.0, Repose is consumed as a git dependency pinned to a release tag. Publishing to crates.io starts at 1.0, which happens when the motion-planning, servo and robot-bridge APIs are stable. From then on, normal SemVer applies and breaking changes need a major version.

What comes next

The next step is real hardware. Already merged for the next release is repose-robot-interface, a vendor-neutral contract for robot bridges: a standard set of channels for joint state and commands, plus a session lifecycle for taking control of a robot, enabling its drives and releasing it again. Every hardware bridge will share these rules, so a program written against one robot doesn't need to change when another robot plugs in. The first robot behind it is the igus ReBeL, over its CRI interface.

After that, the roadmap continues with a production servo loop and collision monitoring during execution.

Repose 0.7 is available today. Update your dependency to tag = "v0.7.0", read the changelog, or start from the getting started guide. Questions or problems with the upgrade? Open an issue on GitHub.