Supporting LTS + 1 and not supporting LTS + 3 might be a bit confusing in
the long run. I think it would be easier to convey that only the Spring
Ubuntu releases are supported (i.e. LTS, LTS + 2). I believe this might be
a good compromise between LTS users and non LTS users.
+1 for Hydro release in July.
On Thu, May 30, 2013 at 6:46 PM, Tully Foote <firstname.lastname@example.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?
> ros-users mailing list
> email@example.com > https://code.ros.org/mailman/listinfo/ros-users >
This message was posted to the following mailing lists: