On 31 May 2013 11:43, Daniel Stonier <d.stonier@gmail.com> wrote:

On 31 May 2013 08:46, Tully Foote <tfoote@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.e.

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

Just realise that this would imply i-turtle and k-turtle have support for 24months, and j-turtle only 12months. That would be fine, though you could also extend support for j-turtle into the first year of NLTS by which time you would hope it had smoothed out the bumps.


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?


ros-users mailing list

Phone : +82-10-5400-3296 (010-5400-3296)
Home: http://snorriheim.dnsdojo.com/

Phone : +82-10-5400-3296 (010-5400-3296)
Home: http://snorriheim.dnsdojo.com/
Yujin R&D: http://rnd.yujinrobot.com/