Closed gavanderhoorn closed 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.
This is actually the same approach I described earlier in https://github.com/JeroenDM/moveit_opw_kinematics_plugin/issues/17#issuecomment-496012864.
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 :)
:(
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.
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.
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).
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:
master
branch (code which compiles for Melodic (and potentially also Noetic, ROS2?))kinetic
branch which "only" contains the changes to undo the Melodic changesSo the
kinetic
branch would revert theIsometry
change and the initialisation difference, but other than that would trackmaster
.If/when
master
gets updated, rebasekinetic
on-top ofmaster
(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 usemaster
(ie: if they are building MoveItmaster
from source on Kinetic).