Support to host groovy-devel branch releases

[j-rivero]

In gazebo_ros_pkgs we maintain two devel branches: hydro-devel and groovy-devel. It would be nice to get releases from both and host them in this same repository. Not sure if full support to making this is in place for bloom.

My approach to a patch:

diff --git a/tracks.yaml b/tracks.yaml
index 2f50b24..813ccf1 100644
--- a/tracks.yaml
+++ b/tracks.yaml
@@ -19,3 +19,23 @@ tracks:
     vcs_type: git
     vcs_uri: https://github.com/osrf/gazebo_ros_pkgs.git
     version: :{auto}
+  groovy:
+    actions:
+    - bloom-export-upstream :{vcs_local_uri} :{vcs_type} --tag :{release_tag} --display-uri
+      :{vcs_uri} --name :{name} --output-dir :{archive_dir_path}
+    - git-bloom-import-upstream :{archive_path} :{patches} --release-version :{version}
+      --replace
+    - git-bloom-generate -y rosrelease :{ros_distro} --source upstream -i :{release_inc}
+    - git-bloom-generate -y rosdebian --prefix release/:{ros_distro} :{ros_distro}
+      -i :{release_inc}
+    devel_branch: groovy-devel
+    last_version: null
+    name: upstream_groovy
+    patches: null
+    release_inc: '0'
+    release_repo_url: null
+    release_tag: 2.3.3_groovy
+    ros_distro: groovy
+    vcs_type: git
+    vcs_uri: https://github.com/osrf/gazebo_ros_pkgs.git
+    version: :{auto}

Note: in the past I added the release_tag to the upstream repo manually. It must not be shared with hydro-devel branch releases.

[davetcoleman]

I'm not sure when the groovy-devel branch was added to gazebo_ros_pkgs but when I was working on it this summer they were the same code. Although currently they are out of sync (changes in Hydro have not been merged into the Groovy branch) I believe we could just remove the Groovy branch. Officially, Groovy isn't even supported since simulator-gazebo exists in Groovy.

[j-rivero]

Probably was created to to host all packages except gazebo_ros_control since dependencies are not available on groovy. We are using the rest of packages in groovy so we don't have to maintain our own fork inside of drcsim package. Please do not remove it.

@hsu can provide more details for sure.

[hsu]

groovy-devel branch was created to be a duplicate of hydro-devel without gazebo_ros_control for lack of dependencies in groovy. Unless there is a cleaner way to tell catkin to "ignore" gazebo_ros_control when the ros distribution is groovy, we may have to keep groovy-devel around.

[wjwwood]

You won't be able to release this with bloom in Groovy because gazebo_ros_control depends on a version of gazebo which does not exist in groovy. Building from source would work though.

@hsu what do you mean by ignore, like you have gazebo_ros_control in a workspace and you build it sometimes with Groovy and other times with Hydro and you want this package ignored in the Groovy case? This seems really weird to me. You can touch a CATKIN_IGNORE file in the folder to have catkin ignore it.

[davetcoleman]

none of the dependencies are available for gazebo_ros_control in Groovy unless you install it from source, as I documented in the installation instructions. But I think that's ok because you have to install gazebo_ros_pkgs from source also in Groovy. Using CATKIN_IGNORE is another way to disable the package instead of branching and having to maintain two separate branches.

[j-rivero]

I would say that 'ignore' this time means to be able to run bloom on this repository ignoring the release of gazebo_ros_control package for groovy.

[wjwwood]

You can ignore packages to be released in bloom using an ignore file (not documented). We use this to prevent release of test_* packages:

https://github.com/ros-gbp/ros_comm-release/blob/master/groovy.ignored

[wjwwood]

The packages which are skipped are listed during the release and in the release log:

https://github.com/ros-gbp/ros_comm-release#ros_comm---1950-0

These packages were explicitly ignored:

- test_rosbag
- test_roscpp
- test_rosgraph
- test_roslaunch
- test_roslib_comm
- test_rosmaster
- test_rosparam
- test_rospy
- test_rosservice

[j-rivero]

I think that this exactly what we were looking for. Thanks.