[ros-users] ROS Release Timeline

Fri May 31 05:27:11 UTC 2013

My vote is to only support the Ubuntu LTS releases.  I can't recall a use
case where robot hardware absolutely required anything non-LTS besides a
backported kernel.  Unfortunately, it looks like we didn't poll which
Ubuntu versions ROS users install on workstations and on robots.  I expect
almost no one uses non-LTS on a robot, but it's likely a good idea to issue
another poll on Ubuntu usage.

Another thought is that the version of ROS that releases alongside the LTS
should also become an LTS with slightly longer support.  I'm not sure that
the entire 5 years is within the resources of our community, but I'm sure
those with long-term deliverables would appreciate at least 3 years in
order to have time to bridge Ubuntu LTS releases.

Therefore, my proposal (similar to Daniel's) is that every other 12 month
ROS release is an LTS, supported for 36 months; and the other release is
used for ROS staging and will bridge the two LTS releases.

>From Igloo on, that should look like:

Igloo LTS released exclusively with Ubuntu T LTS (Supported for 36 months)

J Turtle Released on Ubuntu T  (Supported for 24 months).  Adds Support for
Ubuntu X LTS mid-cycle

K Turtle LTS released exclusively with Ubuntu X LTS (Supported for 36
months)

...

TL;DR: Poll Ubuntu Usage - More LTS

On Thu, May 30, 2013 at 4:46 PM, Tully Foote <tfoote at osrfoundation.org>wrote:

> *
>
> 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:
> https://docs.google.com/file/d/0BzNmzxy4pVGMZHd2b1BSWVlHVHM/edit
>
> 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?
>
> Tully
>
> *
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20130530/321c3001/attachment-0004.html>