[ros-users] ROS Release Timeline

Tue Jun 18 05:10:05 UTC 2013

On Tue, Jun 18, 2013 at 10:23 AM, Tully Foote <tfoote at osrfoundation.org>wrote:

> 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.
>

Looks good to me. So, when can we expect Hydro for Precise? :-)

Marcus

>
>
> 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
>>
>>
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>

-- 
Marcus Liebhardt
Control Engineer
Yujin Robot
주소: 대한민국 서울시 금천구 가산동 345-30 남성프라자 #601, 153-023.
Address: Door #601, Namsung-Plaza, 345-30 Gasan-dong, Guemcheon-gu, Seoul,
153-023, Republic of Korea
Website: http://www.yujinrobot.com
Email: marcus.liebhardt at yujinrobot.com
Phone: +82-70-46577073
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20130618/a1939afa/attachment-0004.html>