Should we target specific release of motoros2_interfaces?

[ted-miller]

motoros2_client_interface_dependencies/source_deps.repos

Line 5 in 8fbe9eb

version: main

This would allow us to say that the latest release of motoros2 is compatible with the latest motoros2_client_interface_dependencies

[jimmy-mcelwain]

I didn't think about that but yeah it would probably make more sense to have the motoros2_client_interface_dependencies be tied to a specific release version. The current strategy doesn't work well for people who are just loading the latest release binaries onto their controller.

[ted-miller]

I don't know what the absolute best solution is. Maybe we could have a new default branch that pulls the motoros2_interfaces release associated with the latest binary, and then a second branch that always pulls main (like now) which will probably be better for people building the latest from source

It could also be that we just shouldn't merge the motoros2_interfaces PRs to main except when we are planning to release new binaries on MotoROS2 that are built with the changes.

I like these ideas. main should always point to what is compatible with the current released motoros2 binary. Then a dev or rolling branch with our latest updates.

@gavanderhoorn, any objection?

[gavanderhoorn]

I don't believe we'd need any new branches.

Typical release process for projects that need specific versions of their dependencies (where some/all dependencies are under control of the project):

1. release leaf dependency
2. release dependencies that depend on the leaf, pin version of (leaf) dependency package to desired/required version
3. repeat step 2 as often as possible, going up the dependency tree
4. release top-level project, pinning versions of direct dependencies to whatever was just released (or the versions required)

Only the final step changes the versions the project is compatible with / released against -- as it's either built against those new versions or is released against them.

Before that last step, all build instructions (and probably automation) will still refer to the 'previous version' -- of both the top-level project as well as the pinned dependencies.

All dependencies only need a single branch (or at least not necessarily a dedicated release branch) as all their dependencies are supposed to only checkout/depend on tagged versions.

This allows anyone to build a cutting-edge version by checkout out HEAD, or a released version by checking out the set of dependencies tagged during the last release.

Concretely, for MotoROS2 and its dependencies:

1. tag and release motoros2_interfaces (this includes bumping the version in package.xml and creating a tag. No need for a GH release)
2. tag and release motoros2_client_interface_dependencies (update version of motoros2_interfaces in source_deps.repos and/or any other dependencies this applies to, bump version in package.xml, create a tag. No need for a GH release)
3. tag MotoROS2. Build against version of dependencies in source_deps.repos (for interfaces anyway). Create a release. State exact version of motoros2_client_interface_dependencies its compatible with (==, to avoid future incompatibilities)

MotoROS2 installation instructions (specifically, the readme of motoros2_client_interface_dependencies) directs users to git clone a specific tag, instead of just HEAD. As that's pinned, all its dependencies are pinned.

Developers can keep building against HEAD or whatever version needed.

This will mean more work managing involved repositories, but that's the price to pay when pinning I believe.

---

Edit: unfortunately the last step will depend on humans, as we have no way of enforcing the MotoROS2 <-> motoros2_interfaces relationship. At least not until Iron/Jazzy, as that's when type hashing got introduced.

---

Edit 2: the above process was always the intended one. We just never got around to it.

[ted-miller]

tag and release motoros2_client_interface_dependencies (update version of motoros2_interfaces in source_deps.repos and/or any other dependencies this applies to, bump version in package.xml, create a tag

MotoROS2 installation instructions (specifically, the readme of motoros2_client_interface_dependencies) directs users to git clone a specific tag, instead of just HEAD

I'm don't fully understand some of your comments. But do you agree that this should not just say main? It should be a specific version tag?

motoros2_client_interface_dependencies/source_deps.repos

Lines 2 to 5 in 8fbe9eb

	yaskawa-global/motoros2_interfaces:
	type: git
	url: https://github.com/yaskawa-global/motoros2_interfaces.git
	version: main

tag MotoROS2. Build against version of dependencies in source_deps.repos (for interfaces anyway). Create a release. State exact version of motoros2_client_interface_dependencies its compatible with

Where do you propose this is done. I like the idea of putting your build_info.yaml into the MotoROS2 release zips.

[gavanderhoorn]

But do you agree that this should not just say main? It should be a specific version tag?

yes, that would pin that dependency to a specific version.

Where do you propose this is done. I like the idea of putting your build_info.yaml into the MotoROS2 release zips.

we could add that file. But it's a lot of lines for just figuring out which version of motoros2_interfaces should be used / is compatible.

We've previously listed the compatible version of motoros2_interfaces in the release notes. See the notes for 0.1.3 fi:

We could perhaps also state it in the readme, as we add that to the release .zips right now.

It would go stale really quickly on GH though.

---

Edit: I would probably suggest we add it to the changelog. That is versioned, so tied to a particular MotoROS2 release, and we can add it to the release .zips.

That would be a good idea in any case I believe.

[ted-miller]

I'm definitely ok with listing it predominantly in the changelog and release notes.

But I still really like the idea of also including the build_info.yaml in the release zip. Any objection?
This allows us to see the complete picture to avoid any shenanigans when debugging. (In this case, I don't see how the versions would get out of sync. But it could be handy somewhere in the future.)