ros_control API changes in Kinetic

[miguelprada]

There's been a change of API for hardware_interface::ControllerInfo in the kinetic-devel branch of ros_control in order to allow controllers to use multiple hardware interfaces. This change breaks the canSwitch and doSwitch implementations here.

The fix is quite straightforward, and I already made it in my fork, but it only makes sense to apply it in a Kinetic targeted branch. If you open such a branch I would be happy to open a PR with my proposed fix.

[carlosjoserg]

That'd be great to have already.

There has been no official release of this package in any distro, and furthermore, I never liked the devel-branch-per-distro thing so common in ROS-wise repos ;)

I'd tell you to PR in master directly, but there is this long-standing PR #46, which I'd like to merge before moving forward to meet newest dependencies... this way I can tag the latest commit before upgrading for the API change as indigo or alike.

So give me a few days to sort out what's missing to merge it so we can move on with this.

Thanks !

[miguelprada]

Sure, I'll add some more changes I didn't notice at first (i.e. canSwitch has been replaced by prepareSwitch in RobotHW), tag the commit with the required changes in my fork and wait for you to be ready.

About the development branches vs tags, don't you think keeping indigo as a live branch is better in case you ever need to backport other changes or even just do some bug fixing?

[carlosjoserg]

About the development branches vs tags, don't you think keeping indigo as a live branch is better in case you ever need to backport other changes or even just do some bug fixing?

You said the magic word, only if you are a believer of backporting, which makes sense for bigger software following LTS releases, like Ubuntu, or for critical or security issues, which it is none of these in this case, I think.

I believe it is better for people to add functionality or even fix bugs on top of the latest, otherwise you might end-up also cherry-picking stuff from people working on previous versions to newer versions, which is very error-prone. It is open-source, so anyone is free to cherry-pick back at his/her own risk on his/her fork if a fix or a functionality is needed while using the package in a previous version of the dependency set.

But as always, a lot of IMHOs, since it is a matter of development styles according to the project, which it is a nightmare anyway when dealing with dependencies, LTS, ROS, etc, etc ;)

[carlosjoserg]

I''ve given a bit of thought on the development style, I think something like this could be good:

Plus the policy of only rebasing&merging in master as the unique development branch, and only cherry-picking back compatible bug fixes or functionality. For instance, for a new release on the latest, say kinetic_release, it boils down to a mere rebase, until a new ROS distro is supported in master.

This way I don't think one misses bug fixes and new features in the latest version. How do you see it?

[miguelprada]

Looks good to me.

That being said, I'm probably not the right person to vet this. My experience with git and release workflows is quite limited yet.

[nstaub]

Looks good to me, although I am also not the right person to vet.

[carlosjoserg]

Thanks for the input @nstaub !

And sorry for the slow response !!

I'm starting to move this...