Versioning strategy clarification

[traversaro]

Hello @ahcorde ! Sorry for opening the issue, but I think it is useful to everyone to understand the current versioning policy used in the repo.

First of all, I think it is worth mentioning that historically this has been a bit of "hybrid" repo, as it has been both released in ROS 2 as a "ROS package" for a long time, but it has also been packaged independently by many upstream linux distributions (https://repology.org/project/urdfdom/versions), even as that is how the package was consumed by sdformat. This has the unfortunately downside that some ROS packages currently depends on the system's urdfdom, and some other on the ROS2's urdfdom, see https://discourse.ros.org/t/proposal-to-extend-jointlimits-in-urdf/42831/2?u=traversaro for a list of such packages. I guess the reason why everything worked until now is that for a long time urdfdom has been ABI stable, and so there is basically now confusion if one version or another gets loaded.

However, lately there have been some activity on the repo that confused a bit me:

• A new major release 5.0.0 was tagged on the kilted branch, without any breaking change w.r.t. to the earlier tag (4.0.1...5.0.0). I was not sure if this release was intentional, see the comment in urdfdom v5.0.0 conda-forge/urdfdom-feedstock#38 (comment) .
• More recently, a 4.0.3 tag on the rolling (default) branch was done, that instead included API and ABI breaking changes (see 4.0.2...4.0.3). The change is not particular problematic, as it removes functions and libraries that were deprecated for ages, however it was a bit unusual to see an ABI breaking changes in a patch release.

So, in a nutshell my questions are:

• what is the current versioning strategy? Was the ABI change in a patch release intentional or not? At the moment in the conda-forge packaging of urdfdom we are assuming that ABI can be broken only on minor releases (see https://github.com/conda-forge/urdfdom-feedstock/blob/eb28cd17c8e8ad9a65e9b41ffbcbe7c0c477d9ef/recipe/recipe.yaml#L32), but if this is not the case anymore, we can change our recipe to track this
• How are tags going to be made in the future? I was kind of expecting for the rolling branch to have the most recent tags and eventually distro specific branches like kilted having minor or patch release, but the fact that 5.0.0 was tagged on kilted and 4.0.3 was tagged on rolling seems to be unexpected.

thanks a lot in advance!

fyi @scpeters @j-rivero

[ahcorde]

This is probably my fault, I removed some deprecated code on rolling I didn't notice the version number in kilted.

I will fix this using the following version numbers:

• urdfdom (kilted): 5.X
• urdfdom (rolling): 6.X

What do you think ?

[traversaro]

Great, thanks! Just to understand, so as long as we skip the 4.0.3 release, we can continue to assume that there will be no ABI non-backward compatibles changes in patch release? If you do not think this may happen, no problem we can switch to expect ABI breakages for any patch release, not sure anyhow if this needs to be reflected on the homebrew packaging somehow (fyi @scpeters).