Release version number policy

[130s]

Spinning off from this discussion about release plan on discourse.ros.org specifically for versioning for ROS1 MoveIt binding.

TLDR; My suggestion for all subsequent ROS1 releases is to stick to the semantic versioning within 1.x.y range.

• Now that MoveIt is moving forward to utilizing major version number in addition to minor and patch numbers, I feel like leaning toward the semantic version Tully refers to where minor version stands for a new feature release and patch version for a bugfix release. So if that's ok Add time-optimal trajectory parameterization (continues #809) #1365 may wait for another feature release. From release maintenance perspective, clearly diffentiating feature and patch releases makes me not just more comfortable but helps making patch release easier (hopeful outcome would be more frequent feature and patch releases at the right time).

• From the cited discussion I see:

  1.0.x ROS Melodic
  1.1.x ROS Noetic

  This gives me an impression that all releases will remain 1.0.x and 1.1.x for Melodic and Noetic, respectively. This might contradict to the semantic versioning I suggested above.
  IMO I don't feel strong reasons to tie the package version specific to each ROS distro like this. Only requirement I see is to securing a way to differentiate different software versions among ROS distros. While this slight complexity can be a downside, this should be not hard to resolve from my experience as long as release maintainers are careful and in sync. So with that there can be a 1.3.x release on Melodic while 1.4.x on Noetic etc.
  I do agree with differentiating major versions between any ROS1 releases and ROS2 releases.

[130s]

So if that's ok #1365 may wait for another feature release.

I think #1326 1.0.1 is ready and awaited to be out, rather than spending more time to discuss. So I crossed out that sentence.

[rhaschke]

As we want to follow the master-branch approach, semantic versioning seems sensible.
However, this also means, that we don't backport to older release branches anymore as we heavily did in the past. Otherwise, this would require additional releases on those old release branches, which go far beyond patch releases.

[130s]

However, this also means, that we don't backport to older release branches anymore as we heavily did in the past. Otherwise, this would require additional releases on those old release branches, which go far beyond patch releases.

Good point. My suggestion might have not been clear on that.

@rhascheke Can you explain your logic why you think following Semantic Versioning lead to not backborting to older releases?

I can't think of a reason where introducing a different versioning to only newer version after 1.x.y disables a backport to older releases. Particularly in MoveIt! 0.x.y there was no semantic version number differentiation other than ROS distro.

[rhaschke]

Backporting API- or ABI-breaking features from master to older release branches (Melodic) would require a new minor version (when strictly following the semantic versioning scheme). However, Melodic only allows 1.0.x versions, i.e. only patches.
If we should decide to release a new minor release also into Melodic in future (because we want to release several ABI- or API-breaking features), than we run into trouble, because we might already have released into Noetic, say as 1.1.x, but we need to take a larger release number, e.g. 1.2.x, for Melodic.

[davetcoleman]

This gives me an impression that all releases will remain 1.0.x and 1.1.x for Melodic and Noetic, respectively. This might contradict to the semantic versioning I suggested above.

Unfortunately I don't think we'll be able to exactly follow semantic versioning as we transition to ROS 2.0. As discussed previously here, newer versions of MoveIt for ROS 1.0 will likely have breaking API changes that deserve a major version increment. For example, we'll probably want to make big changes for ROS Noetic.

However, we're already using the 2.0 version mean ROS 2.0 support. In an ideal world, everyone would switch to MoveIt 2.0 now and we would stop development of MoveIt 1.0. However, that is unpractical, at least for now, for a lot of reasons we've previously discussed.

Instead, MoveIt 1.1 will signify breaking API changes of MoveIt for ROS 1.0. This is pretty similar to how we've always incremented MoveIt in the past, actually: 0.5, 0.6, 0.7 for each new ROS distro in the past.

Overall though, once we have MoveIt 2 fully working I do intend to put a lot of effort into to providing bridges and instructions that make the development switch to MoveIt 2 happen as soon as possible.

[robroboto]

I believe this issue has been resolved and can be closed.