[ros-users] ROS Release Timeline

Daniel Stonier d.stonier at gmail.com
Fri May 31 02:43:09 UTC 2013

On 31 May 2013 08:46, 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.
> *

Took a perusal of the svg's to really sort out the puzzle of words above!

I think groovy was what we would consider a 'staging ground' release for
large changes. We had a vested interest in pursuing groovy for some of our
use cases, but for the use cases where we are interested in using Ubuntu
LTS releases, we probably wouldn't have missed groovy much at all. So I'm
not sure there may be enough interest to warrant investing the effort to
support big staging releases on LTS.

I notice what you've drawn in ubuntu_ros.svg coincides with this thinking -

i-turtle: LTS, LTS+1
j-turtle: LTS+2, LTS+3   <- Staging Release
k-turtle: NLTS, NLTS+1 (Next LTS)

We usually have an interest at Yujin in pursuing both use cases - the
latest *and* the stable (dependant on the project) and I think we could
work with that quite happily. It also provides a mechanism for ros to
introduce potentially disruptive changes (i.e. in LTS+2, LTS+3 releases)
and get real feedback without disrupting the part of the community that
needs to be stable.


> 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

Phone : +82-10-5400-3296 (010-5400-3296)
Home: http://snorriheim.dnsdojo.com/
Yujin R&D: http://rnd.yujinrobot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20130531/b7448442/attachment-0004.html>

More information about the ros-users mailing list