Difference between kinetic and melodic

[JeroenDM]

I'm not sure whether I need a separate kinetic and melodic branch.

This warning suggests I do:

IK plugin for group 'manipulator' relies on deprecated API. Please implement initialize(RobotModel, ...).

(Shows up when running a demo.launch file of a robot configured with this plugin in ros melodic.)

[simonschmeisser]

Yes, melodic has a new way of passing in a parsed RobotModel (also handling joint limits a bit different) instead of parsing it in each ik plugin. I plan to implement that at some point. Otherwise it would be nice to keep them in sync

[JeroenDM]

I already tried changing the plugin to the new interface. It's a small change but nonetheless, I get mysterious Segmentation faults. I will post more details on the error here if I can't resolve it.

The goal is indeed to keep them in sync as much as possible, but forgive me for strange merge commits sometimes. I never knew there were so many options to merge branches :)

[simonschmeisser]

I'll try implementing the new melodic api soonish and see what I get :)

Maybe @gavanderhoorn can give so hints on how to best keep those branches in sync except for smallish api changes?

[gavanderhoorn]

Note: I'm not entirely certain that I understand what is being discussed here, so I may have misinterpreted something.

---

If the changes are local (ie: don't need to incorporate more and more changes), you could consider keeping one branch as the main development branch and the other essentially forking from that with just a commit (or two) added that introduces the changes needed to acommodate for the differences.

Then whenever new commits are introduced in the main development branch, rebase the other branch on-top of the development one -- esentially reapplying the fixups to the then new current cutting edge.

Rebasing will rewrite the history, so if you're going to be releasing this it might not be too nice, but for source builds you could consider doing something like it.

You could of course just merge branches every once in a while, but that would introduce a large nr of merge commits with very little benefit (ie: no real history to maintain).

[JeroenDM]

You interpreted correctly :)

I think will go for the rebase strategy with melodic-devel as the main branch, since this is the latest supported ROS version in this repository.

Maybe I can delete the current kinetic-devel branch and recreate it from melodic-devel to clean up the commit history. At the moment the branches should be exactly the same, but the commit history is not, this could be confusing.

What do you think @simonschmeisser? (Also, are you interested in access rights to this repository?)

[simonschmeisser]

(We only use melodic but I guess that is not very common)

Currently I think kinetic-devel has the cleaner history? So I guess I would agree but the other way around. ;) (You can just rebase and push -f)

I was hoping for something in between those two strategies, but since that probably does not exist I would go for rebasing as long as changes are small and if the branches ever diverge maybe switch to merging in order to keep the history more linear?

(I prefer having my changes reviewed rather than having access rights :) )

[JeroenDM]

I created a new version of the melodic-branch since there were too many conflicts when rebasing and it became very confusing...

At the moment the kinetic-branch is build on travis for both ros-kinetic and ros-melodic. If we update the melodic branch to the new interface we probably need two different travis scripts in the two branches in order to build them on the correct ros version. (This the technique they use in the descartes package for example.)

[simonschmeisser]

now we finally have a difference in #25 :wink:

[JeroenDM]

As a final note on the git strategy. I think it is feasible to just cherry-pick commits from one branch to the other after a pull request, when relevant. I do not expect hundreds of pull requests in the future :)