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)
• 5.x: 5.0.0 => 500, 5.1.0 => 501, 5.X.0 => 50X, 5.XY.0 => 5XY (e.g. 5.12.0)

One more alternative suggestion for OpenCV 5.x.
Use opencv<major> / opencv5 in library names and <minor> as SOVERSION:

• libopencv5_core.so.0 for 5.0.0
• libopencv5_core.so.1 for 5.1.0
• etc

Please use 👍 👎 under this comment.

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

Discussed with @vpisarev @asmorkalov

4.x:

• upcoming release: 4.5.5 with SOVERSION=405
• next release: 4.6.0 with SOVERSION=406
• etc, 4.7.0 with 407, ..., 4.10.0 => 410

5.x:

• will use opencv5 in library name (like epoch, similar to gtk3, qt5, other libraries). see comment above
• SOVERSION is minor second number from OpenCV version: 5.0.0 => 0, 5.1.0 => 1, 5.2.0 => 2, etc

👍

readelf -d /bin/opencv_version

0x0000000000000001 (NEEDED) Shared library: [libopencv_core.so.4.5]

abi_ver is already with 2 versions i.e is already 4.5 , I didn't understood this change ...

change

so.4.5 => so.405

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 .

Scheme is the following:

• 4.5.3 -> .so.4.5
• 4.5.4 -> .so.4.5
• 4.5.5 -> .so.405 (new scheme from this release)
• 4.6.0 -> .so.406
• 4.7.0 -> .so.407
• etc

It might have been implied but not that explicit, does this mean that from 4.5.5, patch releases maintain ABI compatibility?

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?

• OpenCV preserves API-compatibility between minor releases and follows semantic versioning specification.
• Semantic versioning does not apply to ABI compatibility (see https://semver.org/).
• OpenCV does not preserve ABI-compatibility, SOVERSION and DLL suffixes are used to indicate this explicitly.