search

JeroenDM / moveit_opw_kinematics_plugin

An attempt at writing a MoveIt! plugin for opw_kinematics.
http://wiki.ros.org/moveit_opw_kinematics_plugin
Apache License 2.0
7 stars 7 forks source link

Alternative branching strategy #59

Closed gavanderhoorn closed 4 years ago

gavanderhoorn commented 4 years ago

This is really just a suggestion, or perhaps even more of a "hm, this could potentially save you some work" type of comment.

IIUC, the main difference between Kinetic and Melodic are the differences in how the plugin is initialised and the use of Isometry in Melodic.

It could be worthwhile to consider the following branching strategy:

So the kinetic branch would revert the Isometry change and the initialisation difference, but other than that would track master.

If/when master gets updated, rebase kinetic on-top of master (or perhaps merge) to get those changes in. There could be some divergence, so after some time there could be more 'fix commits' needed, but it might be easier to maintain than duplicating all PRs between the two branches.

Users on Kinetic would use the kinetic branch if they are using the Kinetic version of MoveIt. If not, they'd use master (ie: if they are building MoveIt master from source on Kinetic).

JeroenDM commented 4 years ago

I like the idea. Keeping two branches in sync turns out to be slightly more work than I anticipated (doable, but many opportunities to make mistakes.)

I think "undoing" the changes from melodic to kinetic could be tricky, will see.

gavanderhoorn commented 4 years ago

This is actually the same approach I described earlier in https://github.com/JeroenDM/moveit_opw_kinematics_plugin/issues/17#issuecomment-496012864.

JeroenDM commented 4 years ago

Mmm, indeed. Apparently I originally agreed with that approach, with the subtle difference that a commit was added to melodic-devel, instead of adding a commit to kinetic-devel to undo the changes, which could be better given that most developments happened on melodic.

And then this happened...

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 :)

:(

JeroenDM commented 4 years ago

I think the most straightforward approach to resolve this is creating a kinetic branch from the current melodic-devel and manually adding the two commits.

And then remembering that I choose that strategy! Aka, write it in the readme.

JeroenDM commented 4 years ago

I went through the complete diff between melodic-devel and kinetic-devel (using git diff melodic-devel..kinetic-devel). The changes related to the difference between melodic and kinetic are really all over the code base, in the implementation, tests and build configuration. I think the approach with the "undo commits" can cause more problems than it solves, given there complexity.

Maybe an alternative is to consider master (melodic-devel) as the important branch, and merge changes to kinetic once every couple of months in batches, instead of always keeping it up to date.

I do like the new branch names, kinetic and master.

@gavanderhoorn if this sounds like a good idea to you I can start with the release :)

PS: I also found two commits that did not make it into kinetic (2c0353655d205ce0b3e3acd70ab06fb3ee9b0eff and cb92aaf2cd1525975770a29767ce40587291b83e), will create a pull request for those.

gavanderhoorn commented 4 years ago

re: release: sure, I'd be ok with keeping things as they are right now.

It's not too difficult to change all of this later on, even after releases have been made (it's all plain text in a .yaml file).