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.
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
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.
On Fri, May 31, 2013 at 12:27 AM, Chad Rockey
> 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
> TL;DR: Poll Ubuntu Usage - More LTS
> On Thu, May 30, 2013 at 4:46 PM, Tully Foote <email@example.com>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?
>> ros-users mailing list
>> firstname.lastname@example.org >> https://code.ros.org/mailman/listinfo/ros-users >>
> ros-users mailing list
> email@example.com > https://code.ros.org/mailman/listinfo/ros-users >
This message was posted to the following mailing lists: