[Rock-dev] [Rock-users] RigidBodyState is changing

[Javier Hidalgo Carrió]

The list of actions are more into "let's have the right RBS 
implementation" than "let's have a smooth transition to the new RBS". I 
am worried more about the first one than about the second one. I 
understand the second issue is an enormous issue which I don't have 
experience with.

Replacing RBS by a new version will break building all-of-Rock as for 
example already happened in the past when changing vizkit3d.

One possible solution I could see is to create new types, e.g.: 
BodyState and BodyAcceleration. To have them together with RBS and 
RBAcceleration and progressively change to the new types. For example, 
making a warning compilation when using the RBS. Maintainers of each 
package would have time to adapt to the new type (similar to when we 
moved from actuators to Joints).

Thanks for the comments and prompt reply,

Javier.

On 16.04.2015 18:57, Sylvain Joyeux wrote:
> Javier: the plan looks great, and I am very grateful that you try so
> hard to fix the base types ... But there is IMO still the same
> unresolved issues, and that's a lot for an "imminent change".
>
> You put all over the place "changing the type is not that hard". Have
> you already changed to the new type ? How much changes did you need to
> make in your code ? Have you tried building the vanilla (i.e.
> unmodified) all-of-Rock with the new type in ?
>
>  From my perspective, changing a base type *is* hard. It has an effect
> on day-to-day work for all people that have been using RBS. It breaks
> backward compatibility. Having a Deprecated class is, as far as I can
> see, close to useless as RBS is mainly an orogen interface type, and
> one will not be able to connect a Deprecated port to a non-deprecated
> port.
>
> Mixing the two types will be impossible (since they have the same name
> but different ABIs). So, that's all-or-nothing: either you change all
> your code to use the new RBS, or you keep the old one. Mixing stable
> and master will be unreliable at best. Lot of people will probably end
> up using master (with the pain and suffering that entails).
>
> Does someone have any experience for a wide-ranging change like this ?
> How would we get to the point where we *do* have experience before we
> push it to everyone ? How do we avoid just randomly pushing this
> change to everyone, while many people won't have the time and energy
> to migrate to a brand new RBS ?
>
> There is zero documentation and zero experience for a wide-ranging
> change like this, and I currently have the impression that the issue
> of such a change are just brushed off with a "let's do it, it's going
> to be fine". rock-convert exists, but is documented nowhere.
>
> Now, if this "changing RBS is just fine"  is the consensus, I would
> vote for just creating a new type. At least, we would not pretend that
> we're providing a clean upgrade path, and won't upset those of us that
> don't have the time to just migrate to a completely new type that just
> happens to have kind-of the same API.
>
> Finally, you guys seem to push so much towards changing the base
> types. If that's so high in your agenda, it might be time to put the
> effort to make the process butter-smooth by doing the necessary
> toolchain work ?
>
> Sylvain
>
> On Thu, Apr 16, 2015 at 10:54 AM, Javier Hidalgo Carrió
> <javier.hidalgo_carrio at dfki.de> wrote:
>> Hi,
>>
>> RigidBodyState (RBS) is changing. There is a list of imminent actions (1
>> - 10 bullets).
>> Your comments and alternative solutions are very welcome. Write them here:
>> https://github.com/rock-core/base-types/wiki/TranformWithUncertainty-in-base-types#list-of-imminent-actions
>>
>> Javier.
>>
>> _______________________________________________
>> Rock-users mailing list
>> Rock-users at dfki.de
>> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-users