Hi Tully,
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.
Thanks!
Piyush
On Thu, May 30, 2013 at 6: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
>
>
.%20I%20believe%20this%20might%20be%0A>%20a%20good%20compromise%20between%20LTS%20users%20and%20non%20LTS%20users.%0A>%20%0A>%20+1%20for%20Hydro%20release%20in%20July.%0A>%20%0A>%20Thanks!%0A>%20Piyush%0A>%20%0A>%20On%20Thu,%20May%2030,%202013%20at%206:46%20PM,%20Tully%20Foote%20<tfoote@osrfoundation.org>wrote:%0A>%20%0A>%20>%20*%0A>%20>%0A>%20>%20Hi%20Everyone,%0A>%20>%0A>%20>%20As%20a%20follow%20up%20to%20the%20survey%20we%20circulated%20last%20month%20I'd%20like%20to%20start%20a%0A>%20>%20discussion%20of%20what%20the%20best%20timeline%20for%20ROS%20releases%20would%20be.%0A>%20>%0A>%20>%20As%20a%20reminder%20of%20the%20survey%20results%20see:%0A>%20>%20https://docs.google.com/file/d/0BzNmzxy4pVGMZHd2b1BSWVlHVHM/edit%0A>%20>%0A>%20>%20We've%20had%20many%20discussions%20here%20at%20OSRF%20about%20these%20results%20and%20have%20come%0A>%20>%20up%20with%20a%20few%20candidates%20which%20seem%20reasonable.%20%20I'll%20outline%20the%20logic%0A>%20>%20behind%20how%20we%20got%20to%20them%20and%20would%20like%20to%20hear%20what%20you%20think.%0A>%20>%0A>%20>%20Starting%20out%20based%20on%20the%20survey.%20%20We%20had%20a%20majority%20of%20respondants%0A>%20>%20prefering%20a%2012%20month%20release%20cycle%20and%20a%20plurality%20of%20respondants%0A>%20>%20preferring%20a%2024%20month%20support%20period.%20%20These%20two%20number%20nicely%20allign%20with%0A>%20>%20our%20current%20practice%20of%20having%20two%20supported%20ROS%20distributions%20at%20a%20time%0A>%20>%20with%20one%20ROS%20distribution%20in%20development,%20however%20just%20with%20a%20longer%0A>%20>%20release%20cycle.%20%20This%20amount%20of%20parallel%20development%20is%20about%20all%20that%20we%0A>%20>%20think%20we%20can%20support%20as%20a%20community.%20%20So%20based%20on%20this%20I%20think%20there's%20a%0A>%20>%20relatively%20clear%20mandate%20to%20change%20the%20ROS%20release%20cycle%20to%20every%2012%20months%0A>%20>%20with%2024%20months%20of%20support,%20allowing%2012%20months%20of%20overlap%20between%20releases%0A>%20>%20for%20transition.%0A>%20>%0A>%20>%20We've%20put%20together%20a%20nice%20graphic%20see%20ros.svg%0A>%20>%0A>%20>%20Unfortunately%20the%20problem%20is%20not%20quite%20as%20simple%20as%20the%20above%20graphic%0A>%20>%20shows%20as%20we%20need%20to%20build%20on%20top%20of%20other%20platforms.%20%20Ubuntu%20has%20recently%0A>%20>%20updated%20their%20planned%20release%20cycle%20to%20support%20LTS%20for%205%20years,%20but%20non-LTS%0A>%20>%20releases%20for%20only%209%20months%20while%20maintaining%20their%206%20month%20release%20cycle.%0A>%20>%20%20See:%20https://wiki.ubuntu.com/Releases%0A>%20>%0A>%20>%20This%20can%20be%20seen%20in%20ubuntu.svg%0A>%20>%0A>%20>%20This%20change%20for%20Ubuntu%20unfortunately%20makes%20our%20nice%20clean%20plan%20above%20much%0A>%20>%20harder%20as%20it%20is%20impossible%20to%20support%20a%20release%20for%20anywhere%20near%20close%20to%0A>%20>%2024%20months%20on%20non-LTS%20Ubuntu%20distros.%0A>%20>%0A>%20>%20We%20started%20out%20be%20assuming%20we'd%20release%20ROS%20in%20the%20spring%20to%20coincide%20with%0A>%20>%20the%20LTS%20Ubuntu%20Release.%20%20If%20we're%20planning%20a%201%20year%20release%20cycle,%20the%0A>%20>%20quick%20answer%20is%20that%20for%20the%20intervening%206%20month%20Ubuntu%20Release%20the%20last%0A>%20>%20ROS%20release%20is%20ported%20forward.%20%20This%20can%20be%20done%20with%20a%20minimal%20effort%20by%0A>%20>%20following%20the%20Ubuntu%20by%20about%201%20month,%20enabling%20a%20ROS%20release%20to%20be%20built%0A>%20>%20against%20the%20current%20release%20and%20the%20upcoming%20pre-release%20Ubuntu.%20(Based%20on%0A>%20>%20past%20experiences%20prebuilds%20of%20Ubuntu%20releases%20are%20available%20shortly%20after%0A>%20>%20the%20previous%20release%20has%20come%20out.)%20With%20this%20basic%20outline%20we%20can%20release%0A>%20>%20ROS%20each%20spring%20and%20support%20two%20Ubuntu%20distros%20each.%0A>%20>%0A>%20>%20In%20recognition%20of%20the%20fact%20that%20many%20users%20only%20use%20LTS%20on%20their%20robots%20we%0A>%20>%20then%20thought%20to%20add%20a%20backport%20of%20the%20ROS%20release%20with%20LTS+2%20to%20build%20on%0A>%20>%20the%20LTS.%20%20However%20the%20fact%20that%20the%20LTS+2%20release%20will%20also%20be%20built%20on%20the%0A>%20>%20LTS+3%20makes%20supporting%20this%20spanning%20set%20very%20hard%20because%20LTS+3%20is%20usually%0A>%20>%20the%20staging%20grounds%20for%20large%20changes%20to%20get%20into%20the%20next%20LTS%20release.%0A>%20>%0A>%20>%20To%20see%20this%20see%20graphic%20ubuntu_ros.svg%0A>%20>%0A>%20>%20To%20resolve%20this%20there%20are%20many%20options.%20%20We%20could%20consider%20dropping%0A>%20>%20support%20for%20LTS+3%20to%20resolve%20the%20large%20spanning%20set.%20%20Another%20option%20is%20to%0A>%20>%20simply%20support%20the%20LTS%20Ubuntu%20Releases%20since%20the%20non%20LTS%20release%20cycles%20are%0A>%20>%20now%20so%20short,%20making%20our%2024%20month%20support%20cycle%20much%20easier.%0A>%20>%0A>%20>%0A>%20>%20You%20will%20note%20in%20this%20process%20that%20we%20have%20decreased%20the%20matrix%20of%20ROS%20vs%0A>%20>%20Ubuntu%20packages.%20%20This%20is%20purposeful%20as%20we've%20identified%20supporting%20the%0A>%20>%20large%20matrix%20of%20ROS%20vs%20Ubuntu%20distros%20as%20a%20significant%20burden%20on%20the%0A>%20>%20community.%20%20Our%20sketch%20is%20laid%20out%20to%20support%20two%20major%20use%20cases,%20a%20stable%0A>%20>%20developer%20who%20wants%20to%20stick%20to%20the%20LTS%20Ubuntu%20release%20and%20the%20cutting%20edge%0A>%20>%20user%20who%20wants%20the%20latest%20version%20of%20ROS%20on%20the%20latest%20Ubuntu%20distro.%0A>%20>%0A>%20>%20Besides%20the%20provided%20Debian%20package%20it%20is%20always%20easily%20possible%20to%20build%0A>%20>%20a%20ROS%20distribution%20from%20source.%20It%20only%20requires%20running%20a%20handful%20of%0A>%20>%20commands.%20%20A%20complete%20build%20of%20desktop-full%20takes%20about%203-4%20hours%20of%0A>%20>%20compilation%20time%20on%20a%20recent%20Intel%20i7%20machine.%20This%20is%20the%20workflow%20that%0A>%20>%20every%20non-Ubuntu%20user%20uses%20which%20has%20been%20continuously%20improved%20as%20we%20have%0A>%20>%20upgraded%20the%20core%20tools.%0A>%20>%0A>%20>%20And%20the%20last%20consideration%20is%20when%20should%20we%20release%20Hydro,%20we%20have%20close%0A>%20>%20to%20half%20the%20packages%20for%20Hydro%20released%20and%20I%20know%20many%20of%20the%20remaining%0A>%20>%20packages%20which%20were%20in%20the%20initial%20groovy%20release%20are%20preparing%20for%20the%0A>%20>%20hydro%20release%20at%20the%20moment.%20%20From%20the%20considerations%20of%20synchronizing%20with%0A>%20>%20Ubuntu%20LTS%20it%20seems%20like%20a%20good%20target%20for%20Indigo%20Igloo%20will%20be%20April/May%0A>%20>%202014%20leaving%20us%2011%20months%20from%20now.%20%20As%20a%20straw%20man%20for%20Hydro%20I'd%20propose%0A>%20>%20July%20giving%20the%20Indigo%20cycle%209%20months%20following%20Hydro%207%20months%20to%20ease%20us%0A>%20>%20into%20the%2012%20month%20cycle.%0A>%20>%0A>%20>%20Please%20let%20us%20know%20your%20thoughts?%0A>%20>%0A>%20>%20Tully%0A>%20>%0A>%20>%20*%0A>%20>%0A>%20>%20_______________________________________________%0A>%20>%20ros-users%20mailing%20list%0A>%20>%20ros-users@code.ros.org%0A>%20>%20https://code.ros.org/mailman/listinfo/ros-users%0A>%20>%0A>%20>%0A>%20 "Reply to this message")
(text/plain)