@jrivero FYI I bumped this into the Release category as it’s best targeted at maintainers.
And there’s details per distro here: http://wiki.ros.org/Distributions/ReleasePolicy with LTS vs on-LTS. Note that Kinetic is also an LTS.
Our original versioning policy was here: http://wiki.ros.org/StackVersionPolicy but we’ve relaxed this as it was too burdensome.
As a general guideline I like to refer people to Semantic Versioning
I’ll note that our convention is a little bit different that Semantic Versioning in that we typically use patch releases for bug fixes as well as added functionality, as long as it is backwards compatible. And iterate the MINOR version between ROS distros. This is something we might want to consider changing, and suggesting that we follow the slightly more strict guidelines developed since then in semantic versioning. And then we could recommend that only major version changes go into new distros for stable packages.
One of the challenges is that we have a lot of packages in the greater ROS ecosystem and they are not all at the same level of maturity.
At the core we work very hard to maintain full ABI compatibility within any ROS distro for the life of the distro. We also make sure that any API changes have a full deprecation cycle of at least one ROS distro before an API is removed.
However, there are many users using ROS packages to collaborate fluidly on short term projects and need to have more flexibility. Binary builds are a very powerful tool for easy deployment and collaboration, and these faster moving projects cannot maintain the stability while still being productive. As such we do not mandate a specific policy for all packages. The important thing is to clearly document the level of stability for a given package. We do have a few states in the rosdistro status field defined in REP 141 but it’s not really adequate. Better communication of the maturity would be helpful. This was discussed in the package.xml format discussions but could not reach consensus so was left out of the specification.
We also try to manage expectations by only promoting packages to be inside the
desktop-full if we consider them stable.
As a rule of thumb the more dependencies any package has the more stable it’s development process should be. As every incompatible change requires all dependent packages to update.
Our buildfarm makes no assumptions about ABI stability for any given release, and can successfully rebuild everything if there’s an ABI change. However, this may break a user who only does a partial system update. We have discussed explicitly versioning the ABI and in the future would like to be able to be more explicit about it. But ABI versioning has many different approaches and we could not find a consensus during the discussions so deferred the decision.