ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org

Melodic Morenia Buildfarm Available

Greetings ROS users,

We’re excited to announce the availability of the buildfarm for the next distribution of ROS, Melodic Morenia!

Current Status of the release:
The targeted platforms and minimum requirements are specified in REP-003. As of today 94 packages have been released into Melodic with binaries available for Ubuntu Bionic and Artful as well as Debian Stretch.

To make the release as convenient as possible for our beloved maintainers, we have a status page keeping track of which repositories have been released compared to ROS Lunar. This page allows you to see if your repositories are releasable, and also shows what dependencies are not satisfied (if any) and all the repositories depending on your repositories.

Call for action to all maintainers:
If the status page shows that you can already release your package, please consider getting a Melodic release out soon. If your package is blocked, please use the melodic release category to coordinate with the maintainers of packages blocking your releases.
Make sure that you have the latest version python-bloom and python-rosdistro before starting your release.

Please record any API changes or major behavioral changes in your package
on the Migration wiki page for Melodic.

Once your package has been added to Melodic in rosdistro, you can generate
a prerelease command on prerelease.ros.org. Before running the prerelease make sure that python-ros-buildfarm is up to date.

The Melodic release date is May 2018, but it’s good to get started early (especially if many packages depend, directly or indirectly, on yours)!

Your friendly ROS Team

I’m not sure where exactly to ask so I’ll just piggyback here:

Are there plans to add a kinetic builds for Bionic Beaver? Or are these expected to be compatible due to the usual backward compatibility on linux? We run our software which is based on MoveIt! and rviz on kinetic on xenial and I would love to switch to bionic as soon as possible. ie not wait until all our dependencies have been released for melodic.

Unfortunately, no supporting new Ubuntu release with existing ROS distributions is an explicit anti-goal. This is because the changes in dependency versions between Xenial and Bionic would often require changes in our packages and new releases of those packages, which is essential the majority of the effort involved in releasing a new ROS distribution.

As an example, the process of getting rviz or moveit released into melodic versus released in Kinetic but on Bionic, is basically the same:

  • you need all your dependencies to be {in melodic, re-released into kinetic with bionic support}
  • release your package and make sure it works {in melodic, in kinetic on bionic}

The only real difference is that with melodic you need to adjust your code to adapt to changes in your dependencies since the last ROS release, but we try to keep these changes small in the core. So a preference is placed on doing the new ROS distribution rather than forward porting an existing ROS distribution.

As @wjwwood mentioned there’s specifically not plans for Kinetic to be built on Bionic Beaver. Target platforms are listed in REP 3

If you want to use Kinetic on Bionic however in general it will work if you build from source.

http://wiki.ros.org/Installation/Source

As an early adopter on an unsupported platform you will likely find some of those issues that the maintainers will triage during the Melodic release cycle.

Another option you may want to look at is running some of your system in a Docker container. http://wiki.ros.org/docker/Tutorials/Docker for things that are not yet released into Melodic.

What is the reason for supporting non-LTS releases of Ubuntu which are only supported for another 2 months after releasing a long-term supported ROS version? I.e. if ROS melodic gets release in May and Ubuntu Artful (17.10) EOL is July, are there actually people using a LTS ROS on a non-LTS Ubuntu during these 2 months?

I actually think that supporting non-LTS Ubuntu versions (build farm resources, forum support) is not very efficient and other long-term Linux distributions or versions could be supported instead (CentOS, …).

1 Like

I think this topic of releasing for non-LTSs and supporting alternate distro has been touched on a few times. I recall @tfoote discussing this last year, so I’ll just link to that thread here for reference:

In my lab, we’ve never really use non-LTS ROS or non-LTS ubuntu releases, let alone other combination of with. Although, we do use previous ROS LTS with a newer Ubuntu LTS rather often, such as when working with or Fetch robots still locked at 14.04-Ubuntu/Indigo-ROS (due to closed source driver) from our labs workstations running 16.04-Ubuntu for better desktop software. As @tfoote suggested, we’ve manly been getting by using Docker containers to cross over the distro gab.

In fact, recently we’ve taken to containerising every ROS node on the robot as so we could upgrade to 16.04 on our fetch robots, then use 14.04 imaged container to just run the binaries for fetch hardware drivers. For the rest of the fetch stack that is open source, we use a docker registry on a local lab server to automatically rebuild and deploy those packaged images nightly on 16.04 images to streamline with the rest of our custom packages we maintain from 16.04 workstations.

I would be interested in a community survey as to the distribution of users across ROS/OS comonations, just to see what the current landscape is at large. The last time this came up, I think one of the better justifications for non-LTS releases was to afford maintainers time to test and migrate to newer upstream libraries to coincide with Ubuntu’s tick-tock cycle. Of course maintainers can always build everything from source, but with robots, testing your stack sometime requires testing your package against everything else you need to run the robot. Having a ROS disto binaries released into the OS your developing with can help reduce the debug time in packages that are not your own.

2 Likes

I attach past discussion related to this topic. I re-read past @130s, @tfoote and @dirk-thomas’s answer, and I agree with their opinion and it is plausible, but the opportunity cost is much higher than the benefit. Let’s try to discuss this topic again. :slight_smile:

1 Like

Hi @jeovanny

Thanks for your questions.
However ROS Discourse is for news and general interest discussions. ROS Answers
http://answers.ros.org/ provides a forum which can be filtered by tags to
make sure the relevant people can find and/or answer the question, and not
overload everyone with hundreds of posts. So we recommend users to ask their questions there following our support guidelines: http://wiki.ros.org/Support.
You can also find valuable resources to get started with ROS on the ROS wiki that should answers most/all the questions above.