[Rock-dev] Minutes of Rock Core videoconference

[Sylvain Joyeux]

On Tue, Feb 17, 2015 at 4:55 PM, Janosch Machowinski
<Janosch.Machowinski at dfki.de> wrote:
> I vote for a more dynamic scheme on deprecation.
> Deprecation should be possible at any time in master.
This policy proposed that one can always *deprecate* in master. What
you can't do is randomly break backward compatibility.

> This is the reason, why we created releases in thY
> first place, so that we can do drastic changes.
That's your interpretation. I personally like releases so that I can
do *dangerous* changes. And break backward compatibility when I have
no other choice (for the record, orogen_loaders is the fourth attempt
I made at refactoring orogen .. and the least intrusive). Randomly
breaking backward compatibility is just a recipe for rendering a piece
of software completely useless to anybody but its developers. ROS
users were regularly two releases behind *because* migrating to each
new ROS release was a pain (I don't know if it is still the case, but
it definitely was at the time of Electric)

Finally, this policy would apply only on rock-core packages.
Individual maintainers  can always do whatever the f... they want for
non-core packages. And pay the price - I can say for myself that I
won't depend on packages that regularly break backward compatibility.

> 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.
In the case of base/types, it only shows that the people who actually
cared (a.k.a. me in the case of base/types) did not have a good policy
in place and had more important things to do than discuss one at the
time. Can't say for other packages. In fine, the deprecated code which
is still here has zero maintenance cost. Because if it *had* a
maintenance cost, it would be removed already.

> 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.
And that actually might be the best choice. And, by the way, the path
some people are getting into to phase out RBS (ref: the pull request
for TransformWithUncertainty)

> 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.
You of all people should know that autoproj has support to display the
warning messages - given that you're the one who made the original
patch - but at the time there was no consensus whether it should be
enabled by default or not. Care to reboot that discussion ?

Sylvain