[Rock-dev] Minutes of Rock Core videoconference

Jakob Schwendner jakob.schwendner at dfki.de
Wed Feb 18 09:08:35 CET 2015


> We got a bunch of old stuff lying around, that was marked as deprecated,
but
> never cleaned up (good example are the backward compatibility header in
> base). This shows, that the current system of marking an cleaning up later
is
> not working, because people forget about it, or just don't care.
True. That was the reason for the introduced removal with optional reversal
by adding a compile flag.
I think it could work, and it allows people to take more time with changing
their code without having 
to stick with old versions.

> Also the suggested method is not feasible for incompatible changes to
> existing types. These need to applied right away, or you end up with
> something like RigidBodyState31.
That is true. I don't really have a good idea how to handle this. But maybe
RigidBodyState31, which encapsules your current RigidBodyState is actually a
possibility for critical types. 

> Another point is, that autoproj suppresses all compile warning (yea, I
know
> there is the X warnings line). So most people will never see the
deprecation
> warning in the first place, if they do not explicitly look into the log
file.
But you see it when you develop on a package, and accidentilly use an old
type. But agreed, something like -DDEPRICATED would be much more effective,
up to the point that we could use it as our only method. And ignore the
messages.

While backward compatibility is important, we need to have a balance that
allows us to innovate without too much work.

Cheers,

Jakob



More information about the Rock-dev mailing list