[ros-users] [Discourse.ros.org] [General] Proposed changes to the ROS releases

Wed May 9 12:48:24 UTC 2018

Based on the results of our recent survey (https://discourse.ros.org/t/ros1-2018-version-survey-the-results-are-in/4547), as well as the download statistics that were posted last year (http://download.ros.org/downloads/metrics/metrics-report-2017-07.pdf), Open Robotics is proposing some changes to the ROS release schedule that should reduce the support burden on maintainers and on Open Robotics itself.  The proposals below are roughly ordered from having the least impact to the most impact:

# Continue releasing a ROS LTS every 2 years

* Conclusion: There is high use and demand for the ROS LTS releases.

* Proposal: Keep releasing the ROS LTS on a 2 year schedule, as is currently done.

# Stop targeting non-LTS Ubuntu distributions with ROS LTS

* Conclusion: There is very low adoption of the non-LTS Ubuntu distributions by users.  The non-LTS Ubuntu versions are only supported for a short time after the ROS LTS release.

* Proposal: Stop targeting non-LTS Ubuntu distributions with ROS LTS releases.

* Consequences:

  * No ROS LTS binaries for non-LTS Ubuntu releases.

  * No need to support non-LTS Ubuntu releases for packages in ROS LTS.

  * Instead of using non-LTS Ubuntu releases users can use the Ubuntu enablement stacks (HWE), e.g. 16.04.4.

  * May be more difficult for users to build from source on non-LTS Ubuntu distributions since it is not tested in any automated way.

# Only support one version of Debian with one ROS LTS

* Conclusion: Having a Debian release span two ROS LTS releases prevents us from using newer system dependencies.

* Proposal: Only support one version of Debian with one ROS LTS.

* Consequences:

  * A Debian release would only be associated with the first ROS LTS released while the Debian release is also available.

  * Some ROS LTSs may have no Debian version associated with it.

# Replace the non-LTS ROS release with a rolling ROS distro

* Conclusion: There is very light usage of the ROS non-LTS releases.

* Proposal: Only release ROS LTSs, and create a rolling ROS distro based on the last ROS LTS to exist between ROS LTSs.  The goal is to reduce the workload on both maintainers and Open Robotics by removing a distribution which has only a few users.  To compensate for the large gap between releases, the rolling ROS distro will allow maintainers to depend on newer system dependencies and get advanced notice if the next Ubuntu release will have API breaking changes that packages need to deal with.

  * As a starting point the rolling ROS distro would take package releases from the latest ROS LTS.

  * Maintainers could optionally opt-in to specifying newer versions of their packages (newer than the version in the LTS) for the rolling ROS distro by providing additional information.

  * The buildfarm (http://build.ros.org) will periodically attempt to build packages in the rolling ROS distro only on the latest released version of Ubuntu (in the first 6 month the Ubuntu LTS, later only the latest non-LTS Ubuntu), notifying maintainers on failure.

  * (optional) The result of these periodic jobs could be made available as a monolithic archives, e.g. a `.zip` or `.tar.gz` file, which would contain all the packages which built successfully. This avoids making users build all packages from source.

* Consequences:

  * No future ROS non-LTS releases will be created.

  * Users that want to use the latest code must build from source to do so, unless we elect to make fat archives of the periodic builds available.

  * The buildfarm would *not* produce any Debian packages for the rolling ROS distro (in order to not require running bloom for future Ubuntu distros).

Please let us know what you think about each of these proposals.

Your Friendly ROS team

---

## Options discussed for non-LTS ROS releases

While discussing the option of dropping the non-LTS ROS releases, we came up with a number of different things we could do.  The following is a complete list of the options we discussed, with some details of the pros and cons we see on each approach.

* Have a rolling ROS distro targeting the latest Ubuntu release (this is the option we recommend).

  * Pros

      * Ability to automatically detect changes in Ubuntu dependencies that may break ROS packages when updating to a newer Ubuntu release.

      * (optional) Zip archive allows people to use binaries.

      * Packages can use the new functionality from Ubuntu dependencies.

  * Cons

      * Could make ROS LTS less stable - maintainers may push more stuff into ROS LTS to get binary packages.

      * Few users want to use non-LTS Ubuntu releases.

* Have a rolling ROS distro, targeting the latest Ubuntu LTS only.

  * Pros

      * The base Ubuntu platform is used by many users.

      * Ability to automatically detect changes in ROS dependencies that may break ROS packages.

      * Maintainers can release an unstable version of their packages on a base Ubuntu platform used by many users.

      * Easier for users to test the rolling ROS distro since it is the latest Ubuntu LTS.

  * Cons

      * No ability to automatically detect changes in Ubuntu dependencies that may break ROS packages when updating to a newer Ubuntu release.

      * Users or packages cant easily use new functionality from new Ubuntu releases.

* Have a rolling ROS distro, targeting both the latest Ubuntu non-LTS and the latest Ubuntu LTS.

  * Pros

      * Packages tested against stable Ubuntu dependencies and against newest Ubuntu dependencies.

  * Cons

      * If users want to use newer versions of dependencies, their code needs to build for both the current Ubuntu LTS and the latest Ubuntu.

      * Might be painful for maintainers to maintain code handling all Ubuntu versions as specified above.

* Do nothing, keep the ROS non-LTS releases as is currently being done.

  * Pros

      * Keeps the status quo.

   * Cons

      * Maintainers have to release/re-bloom their packages every year for a small userbase.

      * Some maintainers do not release into the ROS non-LTS releases, so those releases are always less complete.

      * Open Robotics needs to do work every year for very small userbase.

* Just do a ROS LTS release every two years, with no additional infrastructure provided in-between.

  * Pros

      * Package maintainers and Open Robotics only *have* to do work every 2 years.

  * Cons

    * Large Ubuntu platform delta between ROS releases, possibly leading to lots of API breaks due to Ubuntu platform dependencies changing.

    * A full tick-tock cycle of API deprecation/removal would take 4 years (2 full ROS releases).

---

[Visit Topic](https://discourse.ros.org/t/proposed-changes-to-the-ros-releases/4736/1) or reply to this email to respond.