[Documentation] [TitleIndex] [WordIndex


This was discussed heavily on ros-users: http://lists.ros.org/lurker/message/20130530.164632.e77ffdf7.en.html as well as a survey which you can download the pdf summary of the results from: https://docs.google.com/file/d/0BzNmzxy4pVGMNDdxNFNDblJTN1k/edit?usp=sharing

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


From the survey there is very strong support for an long term support of ROS(ROS going forward) in sync with Ubuntu LTS(LTS going forward), so we will start with that as the premise of this proposal. We believe that we have built a consensus around a one year release cycle which would make every other ROS release an LTS ROS release.

Release Policy

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

Release rules:

Side effects of the release policy:

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 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 will aim to release half as often as Ubuntu on the April Ubuntu releases (.04 releases). We also typically lag behind their release by about a month, so that means that you can expect a ROS release each year in May.

Normal ROS releases will be supported for two years across a set of Ubuntu releases. LTS ROS releases will be supported for the lifetime of the LTS it is released on, so five years give or take a month.

All ROS releases will be supported on exactly one LTS Ubuntu release. This means that all normal ROS releases will share a Ubuntu release with an older LTS ROS release. However, it also means that a ROS LTS release will never share a Ubuntu release with an older version of ROS.

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.

2019-05-18 12:18