While looking at the Debian packaging for cpdb-libs-2.0~b7 I saw that some ...

[alteholz]

... symbols have been removed since cpdb-libs-2.0~b5. According to [1] in this case the soname has to be changed as well. I would suggest a value of 3:1:0

• "revision" has to change
• "current" needs to be increased as interfaces have been removed
• "age" stays the same as ABI is not backward compatible

I would be glad if a version cpdb-libs-2.0~b8 could be released.

[1] https://autotools.info/libtool/version.html

[tillkamppeter]

Which symbols got actually removed? And with which commit? Perhaps this is a bug or oversight and we can re-introduce them, ideally as a wrapper which calls an existing function or as pseudo-symbol, to satisfy consistency checks of distro build servers.

[alteholz]

According to dpkg-gensymbols the following symbols are missing in b7 compared with b5:

--- debian/libcpdb2t64.symbols (libcpdb2t64_2.0~b7-1_amd64)
+#MISSING: 2.0~b7-1# cpdbConcat@Base 2.0~b5
+#MISSING: 2.0~b7-1# cpdbExtractFileName@Base 2.0~b5
+#MISSING: 2.0~b7-1# cpdbGetStringCopy@Base 2.0~b5
+#MISSING: 2.0~b7-1# print_backend_call_cancel_job@Base 2.0~b5
+#MISSING: 2.0~b7-1# print_backend_call_cancel_job_finish@Base 2.0~b5
+#MISSING: 2.0~b7-1# print_backend_call_cancel_job_sync@Base 2.0~b5
+#MISSING: 2.0~b7-1# print_backend_call_get_active_jobs_count@Base 2.0~b5
+#MISSING: 2.0~b7-1# print_backend_call_get_active_jobs_count_finish@Base 2.0~b5
+#MISSING: 2.0~b7-1# print_backend_call_get_active_jobs_count_sync@Base 2.0~b5
+#MISSING: 2.0~b7-1# print_backend_call_get_all_jobs@Base 2.0~b5
+#MISSING: 2.0~b7-1# print_backend_call_get_all_jobs_finish@Base 2.0~b5
+#MISSING: 2.0~b7-1# print_backend_call_get_all_jobs_sync@Base 2.0~b5
+#MISSING: 2.0~b7-1# print_backend_call_get_printer_list@Base 2.0~b5
+#MISSING: 2.0~b7-1# print_backend_call_get_printer_list_finish@Base 2.0~b5
+#MISSING: 2.0~b7-1# print_backend_call_get_printer_list_sync@Base 2.0~b5
+#MISSING: 2.0~b7-1# print_backend_call_print_file@Base 2.0~b5
+#MISSING: 2.0~b7-1# print_backend_call_print_file_finish@Base 2.0~b5
+#MISSING: 2.0~b7-1# print_backend_call_print_file_sync@Base 2.0~b5
+#MISSING: 2.0~b7-1# print_backend_complete_cancel_job@Base 2.0~b5
+#MISSING: 2.0~b7-1# print_backend_complete_get_active_jobs_count@Base 2.0~b5
+#MISSING: 2.0~b7-1# print_backend_complete_get_all_jobs@Base 2.0~b5
+#MISSING: 2.0~b7-1# print_backend_complete_get_printer_list@Base 2.0~b5
+#MISSING: 2.0~b7-1# print_backend_complete_print_file@Base 2.0~b5
+#MISSING: 2.0~b7-1# print_frontend_emit_hide_remote_printers@Base 2.0~b5
+#MISSING: 2.0~b7-1# print_frontend_emit_hide_temporary_printers@Base 2.0~b5
+#MISSING: 2.0~b7-1# print_frontend_emit_stop_listing@Base 2.0~b5
+#MISSING: 2.0~b7-1# print_frontend_emit_unhide_remote_printers@Base 2.0~b5
+#MISSING: 2.0~b7-1# print_frontend_emit_unhide_temporary_printers@Base 2.0~b5
+#MISSING: 2.0~b7-1# print_frontend_get_type@Base 2.0~b5
+#MISSING: 2.0~b7-1# print_frontend_interface_info@Base 2.0~b5
+#MISSING: 2.0~b7-1# print_frontend_override_properties@Base 2.0~b5
+#MISSING: 2.0~b7-1# print_frontend_proxy_get_type@Base 2.0~b5
+#MISSING: 2.0~b7-1# print_frontend_proxy_new@Base 2.0~b5
+#MISSING: 2.0~b7-1# print_frontend_proxy_new_finish@Base 2.0~b5
+#MISSING: 2.0~b7-1# print_frontend_proxy_new_for_bus@Base 2.0~b5
+#MISSING: 2.0~b7-1# print_frontend_proxy_new_for_bus_finish@Base 2.0~b5
+#MISSING: 2.0~b7-1# print_frontend_proxy_new_for_bus_sync@Base 2.0~b5
+#MISSING: 2.0~b7-1# print_frontend_proxy_new_sync@Base 2.0~b5
+#MISSING: 2.0~b7-1# print_frontend_skeleton_get_type@Base 2.0~b5
+#MISSING: 2.0~b7-1# print_frontend_skeleton_new@Base 2.0~b5
--- debian/libcpdb-frontend2t64.symbols (libcpdb-frontend2t64_2.0~b7-1_amd64)
+#MISSING: 2.0~b7-1# cpdbCancelJob@Base 2.0~b5
+#MISSING: 2.0~b7-1# cpdbGetActiveJobsCount@Base 2.0~b5
+#MISSING: 2.0~b7-1# cpdbGetAllJobs@Base 2.0~b5
+#MISSING: 2.0~b7-1# cpdbPrintFilePath@Base 2.0~b5

For example 6c95351 says that cpdbConcat() was intentionally replaced by g_strconcat() and cpdbConcat() shall no longer be part of the ABI. So at least this does not seem like a bug ...

[tillkamppeter]

Originally, I was assuming that while in beta one does not yet need to stabilize the API/ABI and planned to assure its stability only when starting with release candidates.

Now, as distros have picked up on the beta versions (the beta phase has taken very long as the API was built up following the demands of projects of adding CPDB support to the 5 known free software print dialogs (GTK, Qt, Mozilla, Chromium, LibreOffice). Now these dialogs are all implemented with the API provided by the latest release (2.0b7). So we could say that this API we should use for the final release.

Now there are different approaches for finalization:

1. Keep soname but make sure that all distros have a versioned dependency so that the cpdb-backend-cups 2.0b7 package requires the cpdb-libs 2.0b7 (or newer) library package. Would this approach work out? Or would it cause problems with the distro's dependency managements?
2. Bump soname to 3 in upcoming 2.0b8 release, when this release is OK, quickly do RC1 and finalize to 2.0.0. Disadvantage is having release version 2.x with soname 3.
3. Bump soname to 3 and skip releases 2.x altogether, issue 3.0b1 for first testing, then continue with 3.0rc1 and finalize as 3.0.0.

WDYT?

[alteholz]

From my point of view 2. is the best option.

While 1. might work as well, it needs too much work from external people. If the problem can be solved "internally" I would prefer this.
As the version number and soname of a library are totally unrelated, I would not try to keep them in sync either. So 3. would be last on my ranking.

2.08b with soname 3 as the next release would be great. I don't see a reason why RC1 needs to be done quickly afterwards, but ok ...

[tillkamppeter]

@alteholz Sorry for being late on this.

With this PR you propose to change soname from 2 to 3:1:0. Would it not already work just setting it 3?

[tillkamppeter]

Generally, I will follow your suggestion of releasing 2.0b8 with bumped soname.

[alteholz]

With this PR you propose to change soname from 2 to 3:1:0. Would it not already work just setting it 3?

When writing the comment, I thought the increase in the revision is needed.
Thinking about it again, you are right, the new soname should be 3:0:0.

[tillkamppeter]

Change applied with soname being "3" and not "3:1:0", in commit 09f6c1b

Closing this PR. @alteholz thanks for suggesting this change.