You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Maybe we should choose some middle ground, for example only break ABI compatibility in minor releases, but preserve it in patch releases (including dnn and gapi). For me it seems that breaking changes are not that frequent, but by tying users to every patch version we can cause headaches to alternative distribution maintainers: rolling-release Linux distros and C++ package managers (conan, vcpkg, conda).
Unfortunately almost every quarterly release we have some issues with ABI compatibility.
Currently we don't verify ABI compatibility for 4.x releases, so we can't properly track when we need to update it.
Please note, that compatibility tool doesn't work with GCC 9.x yet (Ubuntu 20.04 uses GCC 9.3) sue to missing compiler support.
5.x series is planed to be released as 5.0.0, 5.1.0, 5.2.0, 5.3.0, 5.4.0, 5.5.0, 5.6.0, etc. Without any .4 minor version limit which we have for 2.x, 3.x and partially 4.x release series (4.5 is released under Apache 2).
We don't plan to release regular patch updates for 5.x (SO version should look like 5XY00 in the proposed 5+ digits scheme)
Alternative is to compress SOVERSION a bit:
4.x: 4.5.4 => 454, 4.5.5 => 455, ... 4.5.9 => 459, 4.5.10 => 460 (50+10=60, as we don't plan to have 4.6 in 4.x release series)
I think that adding version to the name is not a good idea if we are not changing things dramatically. I think that the variant proposed in this PR is good enough without compression.
that compatibility tool doesn't work with GCC 9.x yet (Ubuntu 20.04 uses GCC 9.3) sue to missing compiler support.
Hm? You can use /usr/bin/abidiff from (lib)abigail-tools, which does not depend on any particular compiler support other than that debug info (-g) should be there (for accurate results).
yes and it doesn't "increase SO version on each release" just from release 4.5.x to release 4.6.0 , like it was done before, I mean abi_ver also just change from release 4.5.x to release 4.6.0 but 4.5 to 4.6 .
It might have been implied but not that explicit, does this mean that from 4.5.5, patch releases maintain ABI compatibility?
all versions do not maintain the ABI , that is why on Fedora we have opencv-4.5.2 on F34, opencv-4.5.3 fc35 and 4.5.5 on rawhide , the ABI compatibility is not guaranteed
thanks @sergiomb2 !
So this means that because API compatibility is not guaranteed, OpenCV won't have patch version upgrades anymore. This way OpenCV versions will comply with semantic versioning where patch releases are supposed to keep ABI compatibility. Basically patch version number will always be 0 for OpenCV releases and there cannot be a 4.6.1 or a 4.6.2 release, but only 4.6.0 or 4.7.0. Is this correct?
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
resolves #20878
Library symlinks:
Application information:
outdated initial proposal
Library symlinks:
Application information: