[ros-users] ROS Release Timeline

Top Page
Message as email
+ (text/plain)
+ (text/html)
+ ubuntu.svg (image/svg+xml)
+ ros.svg (image/svg+xml)
+ ubuntu_ros.svg (image/svg+xml)
Delete this message
Reply to this message
Author: User discussions
To: User discussions
Subject: [ros-users] ROS Release Timeline

Hi Everyone,

As a follow up to the survey we circulated last month I'd like to start a
discussion of what the best timeline for ROS releases would be.

As a reminder of the survey results see:

We've had many discussions here at OSRF about these results and have come
up with a few candidates which seem reasonable. I'll outline the logic
behind how we got to them and would like to hear what you think.

Starting out based on the survey. We had a majority of respondants
prefering a 12 month release cycle and a plurality of respondants
preferring a 24 month support period. These two number nicely allign with
our current practice of having two supported ROS distributions at a time
with one ROS distribution in development, however just with a longer
release cycle. This amount of parallel development is about all that we
think we can support as a community. So based on this I think there's a
relatively clear mandate to change the ROS release cycle to every 12 months
with 24 months of support, allowing 12 months of overlap between releases
for transition.

We've put together a nice graphic see ros.svg

Unfortunately the problem is not quite as simple as the above graphic shows
as we need to build on top of other platforms. Ubuntu has recently updated
their planned release cycle to support LTS for 5 years, but non-LTS
releases for only 9 months while maintaining their 6 month release cycle.
See: https://wiki.ubuntu.com/Releases

This can be seen in ubuntu.svg

This change for Ubuntu unfortunately makes our nice clean plan above much
harder as it is impossible to support a release for anywhere near close to
24 months on non-LTS Ubuntu distros.

We started out be assuming we'd release ROS in the spring to coincide with
the LTS Ubuntu Release. If we're planning a 1 year release cycle, the
quick answer is that for the intervening 6 month Ubuntu Release the last
ROS release is ported forward. This can be done with a minimal effort by
following the Ubuntu by about 1 month, enabling a ROS release to be built
against the current release and the upcoming pre-release Ubuntu. (Based on
past experiences prebuilds of Ubuntu releases are available shortly after
the previous release has come out.) With this basic outline we can release
ROS each spring and support two Ubuntu distros each.

In recognition of the fact that many users only use LTS on their robots we
then thought to add a backport of the ROS release with LTS+2 to build on
the LTS. However the fact that the LTS+2 release will also be built on the
LTS+3 makes supporting this spanning set very hard because LTS+3 is usually
the staging grounds for large changes to get into the next LTS release.

To see this see graphic ubuntu_ros.svg

To resolve this there are many options. We could consider dropping support
for LTS+3 to resolve the large spanning set. Another option is to simply
support the LTS Ubuntu Releases since the non LTS release cycles are now so
short, making our 24 month support cycle much easier.

You will note in this process that we have decreased the matrix of ROS vs
Ubuntu packages. This is purposeful as we've identified supporting the
large matrix of ROS vs Ubuntu distros as a significant burden on the
community. Our sketch is laid out to support two major use cases, a stable
developer who wants to stick to the LTS Ubuntu release and the cutting edge
user who wants the latest version of ROS on the latest Ubuntu distro.

Besides the provided Debian package it is always easily possible to build a
ROS distribution from source. It only requires running a handful of
commands. A complete build of desktop-full takes about 3-4 hours of
compilation time on a recent Intel i7 machine. This is the workflow that
every non-Ubuntu user uses which has been continuously improved as we have
upgraded the core tools.

And the last consideration is when should we release Hydro, we have close
to half the packages for Hydro released and I know many of the remaining
packages which were in the initial groovy release are preparing for the
hydro release at the moment. From the considerations of synchronizing with
Ubuntu LTS it seems like a good target for Indigo Igloo will be April/May
2014 leaving us 11 months from now. As a straw man for Hydro I'd propose
July giving the Indigo cycle 9 months following Hydro 7 months to ease us
into the 12 month cycle.

Please let us know your thoughts?