I would highly recommend against only supporting Ubuntu LTS releases. I completely agree with you that robot hardware will probably never require anything other than a backported kernel. However users new to robotics, Ubuntu and/or ROS might have the latest (Non-LTS) Ubuntu release installed for other projects. I think some care should be taken not to disenfranchise these new users from trying out ROS.

I like Daniel's proposal (pasted again below).

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

As an Ubuntu LTS only user, this means that I am going to miss out on a new ROS release for a span of a year (i.e unlikely to use j-turtle). Here's another thought. Would an October release make sense?

h-turtle (released in october with LTS-1): LTS-1, LTS (maintained for 30 months)
i-turtle (released in october with LTS+1): LTS, LTS+1, LTS+2 (maintained for 24 months)
j-turtle (release in october with LTS+3/NLTS-1): LTS+3/NLTS-1, NLTS (maintained for 30 months)

This way, if I like features in j-turtle a lot, I can upgrade to NLTS once released and only have to wait 6 months for the upgrade (which coincides with the median upgrade period), or perhaps even to NLTS beta.

Piyush

On Fri, May 31, 2013 at 12:27 AM, Chad Rockey <chadrockey@willowgarage.com> wrote:
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@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@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users



_______________________________________________
ros-users mailing list
ros-users@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users