-
Notifications
You must be signed in to change notification settings - Fork 692
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
*-devel branches? #23
Comments
+1 to branching to allow C++11 changes However I'm not convinced we want to call it a
This doesn't make sense - you say you only want one branch then you propose two? re: maintenance - I think we should just consider the "indigo" tutorials frozen the moment we release kinetic, and only worry about improving kinetic here forward. But still keep the indigo tutorials for historical reasons / for those on indigo still |
Well, if you see a "jade-devel" branch, are you sure the maintainers mean to tell you that this is the branch you should use with ROS kinetic?
That's why I proposed to add an |
I can't be 100% sure it has been tested and works with Kinetic, but I think most people know (and its the standard) to just grab the latest *-devel version available in the repo. Another benefit of using e.g. I'm not totally against the "master" branch idea and would like to hear more opinions @rhaschke @mikeferguson @130s @wjwwood However if we do decide to switch to having a master branch, we should do it uniformly across all moveit repos. |
I'm not totally against the "master" branch either, however it does seem to run against the majority of ROS-based repos. Most of the repos are using *-devel style branch names. I would say that most users understand that we often skip branching for new releases when we can (a few lucky repos are still able to run off their hydro- or groovy-devel branches). Regardless of what we choose to do, the most important part is to make sure that the rosdistro is up to date at all times (since that will make sure the branch names are up to date on the wiki, etc). |
Having a master branch, it will not be clear which ROS version this one is targeting. Hence I would vote for individual devel branches too. If, say jade and kinetic branches are identical, we could have both of them and let them refer to the very same commit in order to avoid the confusion indicated by @v4hn. |
On Thu, Oct 06, 2016 at 05:25:09AM -0700, Robert Haschke wrote:
A README file in the project folder does the same thing for a I still don't think it's a good idea to create individual branches just because there are multiple ROS distributions out there. |
Agreed. And its extra cherry-picking work for nothing. |
I agree to keep our current
Can't agree more. I've seen a few successful examples of longer-lasting repository that stick to single branch approach. Seems like it requires substantial understanding of Branching per certain version of platforms on the other hand is a workaround that requires less initial effort, and more effort over the course of time but has been accepted very well IMO. As of today I have no doubt that MoveIt! is maintained very well :), so branching works. But if we really want to invest for the future, it might be worthwhile considering consolidating future branches...maintenance activity can get less active at some point unfortunately (hate to sound like a quacking duck without action, but I'm not good enough in cmake. One reason to support the workaround in this regard). |
I am branching moveit_tutorials for Kinetic so we can document changes in the new release |
argh, that fell off my todo list. I just added it back... |
This repository only has a
master
branch at the moment.As we just recently moved to c++11 headers for MoveIt, this module has to be compiled with
-std=c++11
in kinetic/xenial.To support this, we could create individual branches.
We could also provide different tutorial versions there to reflect things like the renaming of
MoveGroup
in kinetic.On the other hand I quite like it to have only one branch of the tutorials because it's more easy to maintain.
I would propose to add an
indigo-devel
branch to the current HEAD and afterward add the c++11 flag tomaster
(and also use theMoveGroupInterface
there later on).This would actually be an application of my "master branch" proposal that we should have discussed at the last meeting...
The text was updated successfully, but these errors were encountered: