<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 29, 2015, at 18:17, Mike Purvis via ros-users <<a href="mailto:ros-users@lists.ros.org" class="">ros-users@lists.ros.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Note here that all the goals that OSRF presents are perfectly achievable<br class="">
using a different strategy: ROS1.5. ROS1.5 means building nodes that talk<br class="">
via the ROS1 protocol, but are built using ROS2 infrastructure and libraries.</blockquote><div class=""><br class=""></div><div class="">Another view of "ROS1.5" would be where APIs (especially the C++ API) are maintained even as the underlying transport and serialization is changed around, an improved node/nodelet/launch scheme is developed, etc.</div><div class=""><br class=""></div><div class="">I support the DDS direction, but it does seem to be an all-or-nothing affair, and that's one of the biggest bummers about it.</div></div></div></div></div></blockquote><br class=""></div><div>I agree with Mike.</div><div><br class=""></div><div>Changing the API and asking the community to migrate is a very high requirement for community members. Personally I think it is too high. I’m motivated by for example, the PR2 community survey (march ’15) where over 70% of the users were 1 or 2 ROS distributions behind. Non-portability of current work was a big motivation in that (52.9%). And this just *between* ROS versions, which is nowhere near to what is being proposed in ROS2. </div><div apple-content-edited="true" class=""><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">So at least maintain the existing APIs. Incrementally improve ROS and add new APIs for new features, as you see fit. Swap out custom technologies for tried and tested newer/better/… Much of this is possible without breaking existing stuff, and moreover it can bring improvements to the existing ecosystem ‘for free’.</div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Have a migration plan with automatized migration tools. (Semi-)automatic source code rewriting is no black magic and it will be a big help e.g. in those cases where an API change is needed. Google does this with Go and it seems to work out well for them (see 'Mechanical source transformation’ in <a href="http://blog.golang.org/go-fmt-your-code" class="">http://blog.golang.org/go-fmt-your-code</a>).</div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">To repeat myself: big bang releases are very risky and very costly. Gradual improvements like above avoid this risk, and may even allow the community to use new features sooner and/or profit from the improvements in the back-end.</div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">---> Save our in-boxes! <a href="http://emailcharter.org" class="">http://emailcharter.org</a> <---<br class=""><br class="">Johan Fabry - <a href="http://pleiad.cl/~jfabry" class="">http://pleiad.cl/~jfabry</a><br class="">PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile</div>
</div>
<br class=""></body></html>