On Tue, Feb 17, 2015 at 4:55 PM, Janosch Machowinski <[email protected]> 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 _______________________________________________ Rock-dev mailing list [email protected] http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
