Question: How to handle wrapper packages tracking upstream releases properly?

[mgruhler]

This question is motivated by a package that I maintain (mgruhler/soem) and how versioning there is currently handled.

It is essentially tracking an upstream repository (OpenEtherCATsociety/SOEM) which is not related to ROS, and provides this upstream repository as a ROS package by wrapping it properly.

The approach so far was to only track releases of upstream and have the ROS package number the same as the upstream release. The goal of this is to avoid confusion as to which upstream version is actually tracked.
As there have been close to no updates to the ROS specific parts outside of releases of upstream, this turned out to be quite ok, and I've simply waited with releases of the ROS package until a new upstream release was there, which happens very seldom, roughly once a year.

However, now there is a PR which adds additional functionality orocos/soem#33 (specifically, it enables Windows builds) that I'd like to integrate and, ideally, release. It is only changing the ROS/CMake plumbing and not the upstream code. So behavior of the wrapped package does not change.

How should a release of this package be handled?

The first idea was to only bump the debian increment (from 1.4.0-1 to 1.4.0-2) and keep the old versioning scheme, though I'm aware that this is bad practice, is not strictly following semver and that there are issues like ros-infrastructure/bloom#258 that highlight this. But given this specific use case and that I don't foresee this happening frequently, would this be ok?

If not, obviously the ROS and upstream package versions have to diverge and it should be made clear in the README (or wherever) which upstream version is tracked. Again, as there are close to no updates that don't come with releases of upstream (but exceptions exist), I'd like to avoid this.

Are there any other ideas how this could be handled?

Some feedback from @tfoote or someone else at OSRF would be highly appreciated.
Thanks.

[clalancette]

We have a similar situation in ROS 2 with cartographer_ros. There is an explanation of how and why we do this at https://github.com/ros2/cartographer_ros/blob/a04a6f35bd79742b18a335b2ecdab1546f0b7bbb/cartographer_ros/package.xml#L20 . We think that works pretty well, though your mileage may vary.

I'm going to close this out assuming that the question has been answered, but feel free to keep commenting or re-open if you still need to discuss more.

[mgruhler]

@clalancette thanks for the idea. This could be a way to encode both, even though it will not resolve the issue with the "confusion" that is there for other users. So a detailed description in the Readme is still required.
I wonder if it wouldn't make more sense to simply highlight the tracked version number in the Readme and clearly diverge from the version number of upstream.

But I'll definitely consider your idea. 👍