[ros-users] ROS Release Timeline

Tully Foote tfoote at osrfoundation.org
Tue Jun 18 01:23:26 UTC 2013


Hi Everyone,

Thank you for taking the time to fill out the survey.  You can download the
the pdf summary of the results from:
https://docs.google.com/file/d/0BzNmzxy4pVGMNDdxNFNDblJTN1k/edit?usp=sharing

Based on the above discussion and the survey results.  We'd like to propose
the following solution.  Dirk's made another nice svg which is attached for
visualization.

>From the survey there is very strong support for an long term support of
ROS(ROS going forward) in sync with Ubuntu LTS(LTS going forward), so we
will start with that as a premis of this proposal. And we believe that we
have built a consensus about a one year release cycle which would make the
ROS+1 release on LTS+2.  Now to fill in the gaps before ROS+2 (the next
long term support) we will need to be able to build more than 6 months
ahead in our 1 year cycle, so we would plan to use LTS+3 as a beta build
ground for ROS+2. And to prepare for ROS+1 we need to be able to build
early enough that we will beta build on LTS+1.  And as there is strong
support for multiple ROS distributions available on LTS, we will also
backport ROS+1 to the LTS.

The net result is as follows:
Ubuntu LTS supports ROS, ROS+1
LTS+1 supports ROS+1 Beta
LTS+2 supports ROS+1
LTS+3 supports ROS+2 Beta
...
LTS2 supports ROS+2, ROS+3


This proposal provides the large userbase who will just use the Ubuntu LTS
releases with two releases.  The other set of users who would like to use
the latest version of Ubuntu are following an aggressive cycle set by
Ubuntu.  For them we can make sure there's at least one version of ROS or
the Beta release of ROS which should be in the soak period before the next
release.


With regards to not tying ROS to Ubuntu only we will also definitely see to
support other platforms.  Right now we do not have the resources or
expertise to support other platforms.  We expect each ROS release to accept
patches for support on other platforms.  This also holds true for other
arches such as arm, which is strongly supported in Q5 of the recent survey.


Related to this it has been suggested to me that we could setup a
bidding/kickstarter style campaign for different platform or arch support.
 If people are interested we could estimate what it would take to support
builds on extra arch/platform combinations for the duration of a release.
 And if there is enough community support to fund the project we can turn
on specific architectures.  Also we are currently building i386 and amd64,
we could consider dropping i386 on some platforms to save resources.

Please take a look at the results of both surveys and the above proposal
and give your feedback.

Tully



On Sun, Jun 2, 2013 at 9:27 AM, Jack O'Quin <jack.oquin at gmail.com> wrote:

> I have read this thread with interest. Many contributors provided well
> thought-out insights and suggestions. I agree with most of what has been
> said, even some that are difficult to reconcile with each other. :-)
>
> On Fri, May 31, 2013 at 4:52 PM, Willy Lambert <lambert.willy at gmail.com>wrote:
>
>> I don't know what's the position about letting ros run on other systems
>> that ubuntu, but if the will is to let it run on several OS flavor (which
>> is the right way to go imo) then sticking to Ubuntu release cycles has just
>> no sense.
>>
>> There will always be several types of users that on one hand will wish
>> high release rate with few changes for agility and on the other one will
>> require very stable grouped release with LTS for stability.
>>
>> "agile" users are required to let the project going ahead as they are the
>> boiling source of idea and great debuggers.
>>
> +1 to all the above. I've been an "agile" user for some projects and an
> LTS advocate for others, depending on the needs of the project. That made
> it hard to give a single answer for some of the questions Tully asked on
> his questionaire.
>
> I would like to see ROS development more closely follow the traditional
> open source model, where the main deliverable is a *source* release
> supported on a wide range of host systems. Ours should support essentially
> all recent Linux distributions, recent OSX releases, and Windows (as best
> we can).
>
> Agile developers can build and work with the sources. If most key
> developers build most things from source, there will be fewer problems
> building on non-Ubuntu platforms. What's more, the tools for doing that
> cleanly and repeatably will continue to improve significantly.
>
> Despite all that, I also think providing "unstable" debbuilds for a few
> recent Ubuntu versions is worth the effort, mainly because of the
> continuous integration and extra testing it could enable. Before, with
> distros coming out twice a year, there was little incentive for users to
> experiment with the "unstable" distro, so it did not accomplish much. With
> longer intervals between distros, that is likely to change.
>
>> As ROS is going into industry (or simply because it s now a mature
>> system), LTS and low feature release rate is a must have. People will soon
>> use ROS in contexts where security and norms are highering inertia of
>> validation step (required after every update).
>>
> Building and hosting Ubuntu packages should be more clearly a separate
> step than it is now. There is already work to make the OSRF build farm and
> other infrastructure portable and documented. That is important. Outside
> organizations need to be able to run their own build farms for several
> reasons.
>
> Many people in industry will need very long-term support, some for a
> duration that OSRF is probably not able or willing to provide. If that
> happens, there would likely be a business case for one or more for-profit
> organizations to supply hosting, build, integration, testing and
> maintenance for whatever set of LTS releases people will pay for. A
> portable build farm would lower the cost of entry for that business.
>
> As an alternative, government, company or industry groups could fund OSRF
> to provide extended support for specific packages and versions.
>
>> Rolling organisation seems adapted to this.
>>
>> About release cycle duration, what's important is to freeze features at a
>> fixed date (cause we always have cooler stuff to add but we need to stop
>> sometime), then let the time required to be stable.
>>
>  Its quite important for people who plans things ahead (they exist !) to
>> see what's happening next as it may triggers heavy updating work behing for
>> users.
>>
> I am not certain what is meant by "rolling organisation".
>
> The ROS distro concept has proven effective for organizing and integrating
> the core packages. In my experience, higher-level packages can often
> support two or three ROS distros with a single source version. That's good,
> and we need to continue providing that kind of API stability.
>
> ROS distro source releases can happen whenever they make sense, mostly
> independent of Ubuntu versions. Of course, the REP-0003 platform
> deliberations become even more important for defining minimum versions of
> various languages, libraries, and Python modules. For example, I'd like to
> see full Python 3 support in the core packages and tools in Indigo.
>
>  http://ros.org/reps/rep-0003.html#platforms-by-distribution
>
> It helps to have a road-map with approximate times in mind. Freeze dates
> are key, with core packages that everything else depends on frozen early.
> The actual release happens only when the release manager decides the
> quality is ready.
>
> --
>  joq
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20130617/a21ec267/attachment-0004.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ubuntu_ros_2.svg
Type: image/svg+xml
Size: 25385 bytes
Desc: not available
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20130617/a21ec267/attachment-0004.svg>


More information about the ros-users mailing list