it's currently almost impossible, to remove redundant methods or cruft like this from opencv's api without breaking the infamous abi check
is there some time-window before upping a release/version number to do this ?
do we have to live with it forever ?
Currently there are two reasons for preserving binary compatibility:
Although, we've discussed this idea recently, some of the proposals were:
But none of these decisions has been taken yet. We will be glad to hear any arguments and ideas.
thanks a lot for the reply & clarification !
i wonder if there would be a way to "collect" or "mark" api breaking changes (pr's), put them into a "freezer" (or even close them temorarily) until the time is ripe, and then pull them out , again (maybe even automatically..)
don't get me wrong, i do think, automated abi checks are nessecary and important, my question is only about how & when to apply changes, which break it.
I think this marking can be made through deprecation attribute, like in flannmodule: https://github.com/Itseez/opencv/blob... Probably some unified CV_DEPRECATED macro can be declared in core module. And then we will need to find and remove all marked functions prior to new ABI-breaking release.
But we need to check whether any problems arise with the described method on all supported platforms.
Also the Doxygen has special @deprecatedcommand which also marks the entities deprecated an collects them all on a separate page: http://docs.opencv.org/master/da/d58/...
Thanks for the clarification. In my honest opinion, I would like something like @berak proposed, where we can collect PR's breaking it, keeping them stacked away, until the time is right. There have been to many decent proposals in the past that had to be removed due to ABI compliance. As to the auto OpenCV packages of linux distros, please lets step away from those also. They are one of the main reasons why people keep using old unupdated and depricated versions :)
Please guarantee binary-level compatibility between major versions. This I think is the best way to avoid dependency 'hell' and most clear to developers and users, especially from a linux background. Semantic Versioning. As a side-note; I personally like the way Intel IPP deprecates functionality and notifies users (link). They mark many things they believe should be deprecated as such and users are encouraged to report if a deprecation of a particular feature will cause problems for them.
I agree to @berak that stuff like that would make life way more easier :)
Asked: 2016-06-02 03:19:10 -0600
Seen: 867 times
Last updated: Jun 03 '16
Last time I had the ABI problem, alalek told me they were at the point of moving to ABI 4.x. So you might want to add alalek to the PR and ask him to keep you posted?
yea, i watched those 50+ comments there lately with a wide grin ;)
let's see, if there's an 'official' strategy for this
(negotiating on a per-case base is obviously a possible idea)
Well as I saw it, adding stuff is quite straightforward by temporarily adding overload classes, that inherit existing stuff. BUT removing or changing signatures is a burden, for example the detectMultiScale that outputs the weights, has the bool by default on false, which is quite unintuitive, since you explicitly select the function to return it.... but since that was once the choice, we need to maintain it ...