ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org

Releasing Different Versions of a Package for Different ROS distros

What is the best way to manage releasing different versions of a package to each ros distro?

I have a package that requires different code to work in Kinetic and Indigo, (OpenCV2 vs 3) and want to release into both. Currently I have indigo-devel and kinetic-devel git branches, which both work on their respective rosdistro (when built from source).

When I release the package, it becomes only a reversion number, which I presume has to be unique across all distros. Is there a standard numbering scheme to use in these circumstances?

Sorry if I missed some documentation somewhere.

Rohan

The version number is proper to one ROS distro. You can have different
version numbers between distros. When configuring with bloom for a ROS
distro, you specify the branch you want your sources to be pulled from (
http://wiki.ros.org/bloom/Tutorials/FirstTimeRelease#Configure_a_Release_Track
)
Concerning OpenCV2/3, it is usually possible to right code that works with
both (cf
http://wiki.ros.org/bloom/Tutorials/FirstTimeRelease#Configure_a_Release_Track).
E.g., vision_opencv has a branch for Indigo and Kinetic but image_pipeline
only one that works for both distros.

1 Like

As far as I understand it, bloom requires that the upstream repo be tagged with the version number.

Git tags are not specific to branches, so do I just prefix the tag with the rosdistro name?

Thanks for the link for dual OpenCV2/3 code, I will see if it makes sense to put effort into that.

Indeed we work hard to provide either deprecation cycles with APIs that can be used with either. Or else simple ways to do #ifdef logic to make it easier for downstream. But sometimes forking the development is either easier or necessary.

If you do fork it’s recommended to start a new series.

In ROS development the most common way to do this is a minor increment for each forked distro.

For example if you have a version 1.0.0 in indigo new releases into indigo would be 1.0.1, 1.0.2 etc. Then if you do not need to change anything for Jade, you can continue to use the 1.0 series. However if you need to fork your development tree you should start a new numbering series and jump up to 1.1.0 for Jade.

Then if you have to fork again for Kinetic you would move up to the 1.2 series, so start with 1.2.0.

There’s a slightly related discussion in this thread where we discuss the actual number selection. And to follow semantic versioning it might actually make sense to increment the major number not the minor number based on our stability requirements.

But to directly answer your question, you’re correct that the tags are independent of the rosdistro. If the code is the same you can use the same releases. However if the code is different you should use a different release numbering series.

Note that you can always jump upward. So if you initially release the same version into Kinetic on a 1.0.x release to match Jade. But then the head diverges you can up it to 1.1.0 for Kinetic and leave Jade on the 1.0.x. One thing to be aware of is that if you fork something for Kinetic to 1.1 where Indigo and Jade are 1.0, and then you want to fork for Jade, you’ve backed yourself into a corner as you need to pick a different higher number series, and you’ll likely end up with jade on 1.3 while Kinetic is on 1.2. But you could jump Kinetic to 1.4 to keep the relative numbering between Jade and Kinetic. It’s not necessary as it’s only required to be monotonic within a distro, but I recommend working hard to avoid this corner case…

1 Like

Thanks for the info, that makes sense.

For now the plan is 0.x for indigo, and 1.x for kinetic, as our kinetic fork was also a refactor/cleanup.

Some time in the future, we are looking to backport 1.x to indigo.
If we go for Jade, it will stay on the same versions as indigo.

Rohan

1 Like