On Mon, Apr 16, 2012 at 10:20 AM, Edwards, Shaun M. <sedwards@swri.org> wrote:

> I wouldn’t want to limit ROS development by imposing backwards compatibility
> requirements.  As ROS and associated libraries become more mature we could
> then impose backwards compatibility requirements.

In my view, the REP process defines interfaces that are mature enough
to persist across multiple releases and implementations. We should use
that to inform compatibility expectations.

> I think what you point out is certifying versions of ROS will require
> significant amounts of testing development effort.  The hope would be that
> the testing software component would not have to be reworked every time we
> decide to created a certified version of ROS, thereby imposing some sort of
> backwards compatibility requirement.  There is certainly a balancing act
> that we as a community need to maintain so that we can have certified
> versions of ROS with commercial acceptance as well as freedom to change and
> develop ROS as needed to meet research objectives.

Well said. I was working on formulating similar thoughts when I saw your post.

I would add that none of these issues are particularly new or unique
to ROS. They mostly boil down to the high costs of testing and
maintenance. Operating systems have been dealing with these for many
decades.

There are several open source models we could emulate. I think the
Ubuntu LTS approach is worth considering: maintaining matching sets of
Ubuntu LTS versions (Lucid, Precise) and ROS "LTS" distributions (TBD)
for several years.

Running and developing compliance tests is a really big job. The QA
group will need to define its scope carefully. Doing that in a shared
community is one of the strengths of open source development.

This is an important discussion, worth a SIG meeting next month at ROScon.
-- 
 joq