*-devel branches? about moveit_tutorials

[davetcoleman]

+1 to branching to allow C++11 changes

However I'm not convinced we want to call it a master branch for the latest version because:

• most people in the ROS community are used to the standard *-devel branches.
• when I see a master branch I'm not sure if the project maintainers actually mean "works with the latest ROS release". But when I see, for example, kinetic-devel I know for sure the intention

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 to master (and also use the MoveGroupInterface there later on).

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

[v4hn]

when I see a master branch I'm not sure if the project maintainers actually mean "works with the latest ROS release". But when I see, for example, kinetic-devel I know for sure the intention

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 the case with e.g. https://github.com/ros-planning/warehouse_ros (this is a more and more common phenomenon ).
And as long as we have no changes specifically for kinetic, it doesn't make sense to add an additional branch there.
Many packages still release their "hydro-devel" branches into kinetic (see here ).
Also the API development of low-level packages in ROS cooled down quite a bit by now and it is often possible to use kinetic branches of some packages in your indigo workspace without too much hassle.
Overall the *-devel scheme becomes more and more obsolete and I prefer a plain master branch and split-off stable branches.

I think we should just consider the "indigo" tutorials frozen the moment we release kinetic, and only worry about improving kinetic here forward.

That's why I proposed to add an indigo-devel branch to support the indigo version, but move forward with a development branch.

[davetcoleman]

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?

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. kinetic-devel is that it makes it a little bit more obvious to new users still using e.g. Indigo that they should switch to the indigo-devel branch. I suspect we would get more error reports from users using the wrong branch if we just had a master - it would at first glance indicate it can work with any ROS version.

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.

[mikeferguson]

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

[rhaschke]

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.

[v4hn]

On Thu, Oct 06, 2016 at 05:25:09AM -0700, Robert Haschke wrote:

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.

A README file in the project folder does the same thing for a master branch. That's how everyone but ROS developers do things out in the FOSS world.
And it even works if someone decides to package MoveIt in Debian, Fedora, Arch, ... and ignores OSRF's release cycle. :)
But ok, I bow to the majority on this issue for now :) .

I still don't think it's a good idea to create individual branches just because there are multiple ROS distributions out there.
Everyone else forks as required at the moment, so I see no problem with making a jade-devel branch available on kinetic as long as we don't have changes particular to kinetic.

[davetcoleman]

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.

[130s]

I agree to keep our current X-devel custom while having a single branch is ideal.

#23 (comment)

On the other hand I quite like it to have only one branch of the tutorials because it's more easy to maintain.

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 cmake as well as coding technique to allow multi-version support. That could lead to tremendous amount of initial effort, but hopefully less maintenance effort over the long period. Although no one can tell, less maintenance could be a key for their long lives.

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

[davetcoleman]

I am branching moveit_tutorials for Kinetic so we can document changes in the new release

ros/rosdistro#12975
ros/rosdistro#12976
#29

[v4hn]

argh, that fell off my todo list. I just added it back...