ros-industrial / ros_canopen

CANopen driver framework for ROS (http://wiki.ros.org/ros_canopen)
GNU Lesser General Public License v3.0
339 stars 271 forks source link

Bloom integration process #327

Closed michael1309 closed 5 years ago

michael1309 commented 5 years ago

Hi,

we have built a ROS node for SICK line guidance sensors on top of your driver. We plan to transfer this ROS node to the distribution via the Bloom release process. Our node depends only on the projects CANopenSocket and ros_canopen. Have you ever done this process before or do you know projects where this process was successfully done?

gavanderhoorn commented 5 years ago

Have you ever done this process before or do you know projects where this process was successfully done?

can you clarify which process you are referring to here, specifically?

michael1309 commented 5 years ago

I refer to the bloom release process following this link: http://wiki.ros.org/bloom/Tutorials/FirstTimeRelease

gavanderhoorn commented 5 years ago

This repository has been bloomed many times, so have countless other ROS packages.

Are you expecting issues, have you experienced issues or are you just asking for guidance?

Our node depends only on the projects CANopenSocket and ros_canopen.

all ROS package dependencies are treated similarly, so this does not influence the release process.

Unless you are trying to release into a ROS version that ros_canopen doesn't support (but Melodic is supported, so that would be difficult).

michael1309 commented 5 years ago

Hello,

That sounds very good. I've only done the Bloom process for a project that didn't have any dependencies. A support with a little hands-on guide on how and where to name the dependencies in package.xml, CMakeLists.txt or in a separate yaml file would be great and a very good help. Thanks in advance! I hope my request is not too "Out of Scope". For your interest: We are talking about https://github.com/SICKAG/sick_line_guidance

gavanderhoorn commented 5 years ago

A support with a little hands-on guide on how and where to name the dependencies in package.xml, CMakeLists.txt or in a separate yaml file would be great and a very good help. [..] I hope my request is not too "Out of Scope".

That would actually be off-topic for this issue tracker, as it's not something that is specific to ros_canopen.

I would suggest to refer to the Releasing a Package for the First Time for the actual release process (the tutorial is something I would consider a hands-on guide). As for the dependencies I would refer you to the catkin documentation. You can use catkin_lint to check your package manifests and build scripts for many common issues.


I'm not the maintainer here though (that would be @ipa-mdl), so I'll leave it to him to decide whether further assistance with a release would be something he wants to handle on this issue tracker.

michael1309 commented 5 years ago

Hi,

Thanks for your hints. I will try to follow the guidelines to resolve the dependencies.

Best regards.

gavanderhoorn commented 5 years ago

Thanks for your hints. I will try to follow the guidelines to resolve the dependencies.

Do your packages build right now?

If the answer is "yes", then there is a large chance that you've already got the dependencies sorted out.

If you want to make sure, try a prerelease, as suggested in the Bloom "first release" tutorial you already linked to.

mathias-luedtke commented 5 years ago

A support with a little hands-on guide on how and where to name the dependencies in package.xml

Just follow http://docs.ros.org/melodic/api/catkin/html/howto/format2/index.html

If you want to make sure, try a prerelease, as suggested in the Bloom "first release" tutorial you already linked to.

As an alternative, you can run pre-release tests with industrial_ci

I'll leave it to him to decide whether further assistance with a release would be something he wants to handle on this issue tracker.

Thanks for your support @gavanderhoorn! As this issue it not specific to ros_canopen I will close it. The provided links should cover all required steps from code preparation to binary release.