Ask Your Question

abi checks

asked 2016-06-02 03:19:10 -0600

berak gravatar image

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 ?

edit retag flag offensive close merge delete



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?

StevenPuttemans gravatar imageStevenPuttemans ( 2016-06-02 03:46:10 -0600 )edit

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)

berak gravatar imageberak ( 2016-06-02 03:48:53 -0600 )edit

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 ...

StevenPuttemans gravatar imageStevenPuttemans ( 2016-06-02 04:09:44 -0600 )edit

1 answer

Sort by ยป oldest newest most voted

answered 2016-06-03 03:45:55 -0600

mshabunin gravatar image

Currently there are two reasons for preserving binary compatibility:

  • Android Manager package released in Google Play; changes can break several applications relying on this package
  • Linux distributions which maintain thier own OpenCV packages; changes can break other packages depending on OpenCV, result in massive package rebuild and complicate dependencies

Although, we've discussed this idea recently, some of the proposals were:

  • probably we can drop Android Manager package support
  • we should keep source-level compatibility between same major versions
  • we can mark obsolete functions as "deprecated" to signal users about future removal
  • we can...
    • either keep binary-level compatibility between same major.minor versions, for example 3.1.0 => 3.1.1 != 3.2
    • either keep binary-level compatibility between same major versions, for example 3.0 => 3.1 => 3.2 != 4.0 (current state)

But none of these decisions has been taken yet. We will be glad to hear any arguments and ideas.

edit flag offensive delete link more


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.

berak gravatar imageberak ( 2016-06-03 04:06:23 -0600 )edit

I think this marking can be made through deprecation attribute, like in flannmodule: 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:

mshabunin gravatar imagemshabunin ( 2016-06-03 05:17:26 -0600 )edit

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 :)

StevenPuttemans gravatar imageStevenPuttemans ( 2016-06-03 05:43:30 -0600 )edit

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.

boaz001 gravatar imageboaz001 ( 2016-06-03 07:32:53 -0600 )edit

why isn't there an abi4 branch or similar ?

breaking changes could be merged into that, and the whole branch into master, when the time has come.

berak gravatar imageberak ( 2016-06-07 22:37:35 -0600 )edit

I agree to @berak that stuff like that would make life way more easier :)

StevenPuttemans gravatar imageStevenPuttemans ( 2016-06-19 15:26:27 -0600 )edit

Question Tools



Asked: 2016-06-02 03:19:10 -0600

Seen: 716 times

Last updated: Jun 03 '16