[Ros-release] ABI compatibility

Daniel Stonier d.stonier at gmail.com
Sat Jan 5 05:18:41 UTC 2013


On 5 January 2013 08:48, Jack O'Quin <jack.oquin at gmail.com> wrote:

>
> On Fri, Jan 4, 2013 at 3:00 PM, Tully Foote <tfoote at willowgarage.com>wrote:
>
>> My best estimate was that rolling over the version numbers to even values
>> would cost us a full week of work for the core team and would require every
>> single maintainer to respond quickly to the request to rerelease.  And
>> availability of all maintainers any specific week is not likely.  Because
>> of this large overhead I didn't ask everyone to comply with that policy.
>>  You'll note I've updated the Version Policy wiki page to reflect that too.
>>
>>
>
+1.

Another comment, that policy indirectly had core ros stacks synchronising
with the 'ros release' number, which was always odd. roscpp for instance,
has only had relatively minor changes over something like 0.6 -> 2.0, but
focusing solely on the version number - that would seem to tell another
story.


>> I think what this points out is that we need to make sure we develop a
>> way to know what versions of packages are available in the debian
>> repository.  And we should make the Changelogs much more visible.  There
>> was a discussion long ago about moving the Changelogs from the wiki back
>> into the source. I think it's time to revive that discussion.  Especially
>> now that we have tools like bloom which could inject that information into
>> the debian packages now.
>>
>> Also we should update REP 9 to not reference the even odd scheme, but be
>> more explicit about when and where things should be compatible.
>>
>
>> And the last thing we should do is find a way to integrate some of the
>> ABI checking tools into the prereleases to help maintainers know when
>> things slip through the cracks.
>>
>
I think this would be a good idea to slip in with the concept of '1.0 is
stable'. Since bloom assumes a major.minor.patch number, you could bring in
the abi tools to generate warnings/errors for any abi breakages in versions
over 1.0.0 and allow freedom to break abi while it is < 1.0.0.

Right now the concept of being 'stable' has no responsibility attached to
it.


>
> +1 to all of that
>
> --
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-release/attachments/20130105/a311e7bc/attachment-0009.html>


More information about the Ros-release mailing list