Revision history [back]

Answer provided by @William via an earlier e-mail conversation:

So, anytime you have changes which cannot go into hydro but go into indigo, you should increment at least the minor version number to avoid exactly the problem you described. You should consider package version numbers (x.y.z) global. The idea is that the minor (y) and major (z) version numbers should only change when new features go in, and once a ROS distro like hydro is released only patches for bug fixes should go into it. That way you should never need to change the major or minor version for a released ROS distro and therefore it is sufficient to increment the minor number when branching to a new ROS distro. People do not always follow this pattern, but it what we use for the core packages. Bloom will not further differentiate the versions, such that version 0.1.1 should be the same for hydro and indigo (if it is released for both). Also, usually we make tags simply x.y.z and we do not use prefixes or suffixes like vx.y.z or anything like that. Though we don't require that you do that, and bloom can handle different tagging schemes as long as they are consistent.

You should be aware of the tools we have to automating the process of preparing upstream for release, like catkin_generate_changelog and catkin_prepare_release described here:

http://wiki.ros.org/bloom/Tutorials/ReleaseCatkinPackage#bloom.2BAC8-Tutorials.2BAC8-PrepareUpstream.Preparing_the_Upstream_Repository

These tools make it a little bit faster to prepare for release and also make the preparations more consistent. So, unless you have a specific need to deviate from this workflow I would recommend using these tools.