move_base_flex: Breaking changes within rosdistro

I agree with @reinzor here, messages should not change within a ROS release. If you consider MBF work in progress you should state so in the package description so people would not use it for production systems. But given that not only Magazino is in fact using it in production I would vote against doing that. The other option is to maintain two branches/releases and do breaking changes only in the unstable/rolling release one.

My 2 cents:

Hacking new message files into the repo to avoid clashes with stable release packages is, indeed, a hack. This adds a new layer for versioning new features on the file level. And it’s a hurdle for developing/refactoring the bleeding edge version IMO. I agree with @jspricke that there should be a distinction between release (stable API) and development code (new features etc.) via branching in this case.

If we want to have stability in a ROS distro release, ideally only important bug patches should be released for that distro and people who need newest features immediately should use a source build from master.

This wouldn’t help with the “5 years without new package” problem though, but I guess that’s a general problem of ROS 1 now… 😕

This package has been released for noetic and noetic is the last ROS1 release. This means there will never be any ROS1 updates possible for mbf_msgs. Just something to consider.

Don’t worry. Since the master’s code (and the changed messages) already existed when we found out that the message changes were the problem for maintaining binary compatibility, we couldn’t take it out, since other software already depends on it.

Message changes will be made only if we change the minor version. So for the next versions 0.3.* there will be no message, service or action changes. Are you fine with that?

We just today encountered again a breaking change from 0.3.1 to 0.3.2 (mbf_msgs different md5 checksum). When our robots are running 0.3.1 and we upgrade our desktop computers, we cannot communicate anymore without upgrading the robot software (which is often not desired).

What are your plan regarding these breaking changes within ROS distro’s? If this is not going to be changed, we might have to work with forks of move_base_flex or abandon the move_base_flex packages.