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