Background

This topic has been discussed heavily:

• http://lists.ros.org/lurker/message/20130530.164632.e77ffdf7.en.html

• https://docs.google.com/file/d/0BzNmzxy4pVGMNDdxNFNDblJTN1k/edit?usp=sharing

• https://discourse.ros.org/t/proposed-changes-to-the-ros-releases/4736

• https://discourse.ros.org/t/planning-future-ros-1-distribution-s/6538

Based on discussion and survey results, we've come to the following policy.

Overview

From the survey there is very strong support for long term support of ROS 1 in sync with Ubuntu LTS(LTS going forward), so we will start with that as the premise of this proposal. Future ROS 1 distros will be made based on available resources and need, with no set schedule beyond Noetic in May 2020.

Release Policy

First is a simplified bullet list about the release policy, followed by a detailed explanation of the policy.

Release rules

• ROS release timing is based on need and available resources
• All future ROS 1 releases are LTS, supported for five years
• ROS releases will drop support for EOL Ubuntu distributions, even if the ROS release is still supported.

Side effects of the release policy:

• Every ROS release will be supported on exactly one Ubuntu LTS.
• LTS releases will not share a common Ubuntu release with any previous releases.
• ROS releases will not add support for new Ubuntu distributions after their release date.

These simplified rules and side effects are subject to change with changes to the underlying Ubuntu release policy.

Detailed Description

Since our default platform for ROS 1 is Ubuntu, our release cycle tracks Ubuntu releases. Ubuntu currently releases a version every half year (x.04, x.10, y.04, y.10, ...). We typically lag behind their LTS release by about a month. If a future ROS 1 distro is created, it would be released in the month of May after the Ubuntu LTS release it targets.

LTS ROS 1 releases will be supported for the lifetime of the LTS it is released on, so five years give or take a month. Previously, there were non-LTS ROS 1 releases supported for two years across a set of Ubuntu releases. These non-LTS releases have been discontinued due to low adoption and high maintenance burden.

All ROS 1 releases will be supported on exactly one LTS Ubuntu release. This means a ROS 1 LTS release will never share a Ubuntu release with an older version of ROS 1.

ROS releases will only support Ubuntu releases as long as they are not EOL. For example, if a ROS release starts out supporting Ubuntu x.04, but x.04 goes EOL before the ROS release, we may stop building packages for the EOL Ubuntu distribution. In this context "drop support" means we will stop triyng to build packages for those EOL'ed Ubuntu distributions.

For example, if ROS distribution A supports Ubuntu x.04 and x.10, then to start any package you release into A will generated binary packages for x.04 and x.10. This means that you need to any dependencies your package has need to be available in Ubuntu x.04 as well as x.10. It also means that if you package doesn't work on one of the Ubuntu distributions then you'll get notified and be expected to fix it. Once we "drop support" for an EOL'ed Ubuntu distribution the previous two consequences will no longer apply for the version of your package in ROS distribution A. So binary packages for Ubuntu x.04 may stop being updated, at the discretion of the people running the build farm. In practice, binaries for Ubuntu x.04 may continue to be built for some time after it is EOL'ed, but generally no effort will be put into fixing them if they fail at some point. You may continue to upgrade the version of your package in ROS distribution A and even add dependencies to it, you will not be required to ensure those dependencies are in the EOL'ed Ubuntu x.04, but it is considered best practice to attempt to not introduce such dependencies, since it will prevent people from manually building your package on Ubuntu x.04.

ROS releases will also not add support for new Ubuntu releases after its release date. For example, if a ROS release is released on x.05 and a new Ubuntu comes out in x.10, then the x.05 ROS release will not support the x.10 Ubuntu release.

Planning your Development

When planning your development, you will occasionally have to release, or re-release software with disruptive changes. That may be just a large set of api changes, or it may be a more significant upgrade of a collection of packages and/or repositories. These will have to be released into the distribution cycle somewhere and you'd like to do it with minimum disturbance to users while at the same time getting good feedback.

A good policy is to make disruptive changes in the current non-LTS ROS release and to be extra careful to not be disruptive to the existing versions in the LTS ROS release. If the newest release of ROS is an LTS, you might consider releasing your disruptive changes into the as yet unreleased next version of ROS if possible, or otherwise stage changes for the next ROS release, but do not introduce them into the LTS release of ROS. Obviously this is not a strict rule, but if you have a user base in the LTS release, they will probably appreciate your attention to stability.