libcmark uses full version number as major dylib version number

On macOS, the libcmark library's major version number (the one contained within the filename and the install name) contains the project's full version number:

% ls -l /opt/local/lib/libcmark.dylib 
lrwxr-xr-x  1 root  wheel  21 Mar 30 05:38 /opt/local/lib/libcmark.dylib -> libcmark.0.30.3.dylib
% otool -L /opt/local/lib/libcmark.0.30.3.dylib
/opt/local/lib/libcmark.0.30.3.dylib:
	/opt/local/lib/libcmark.0.30.3.dylib (compatibility version 0.30.3, current version 0.30.3)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.100.3)

This means that anytime cmark is upgraded to a new version, everything that linked with the library will not work until it has been rebuilt, which is inconvenient.

You are also using the project's full version number as the library's minor version number (labeled "compatibility version" and "current version" in the above output from otool). This suggests a possible misunderstanding of the proper way to version macOS dylibs.

Is it really the case that, for example, libcmark 0.30.3 is incompatible with libcmark 0.30.2?

Normally you should only increase the major version of the library when you make a backward-incompatible change, for example you remove a symbol that was formerly public. You should strive to make such breaking changes as little as possible, with the ideal being never to do that. Note how the operating system's C library, libSystem.B.dylib, is only on its second major version ("B") despite the OS having existed for over 22 years.

Start by locating the macOS dylib build and install-name configuration, then inspect how the project's full version is assigned to the major, compatibility, and current versions. Confirm the intended compatibility policy for libcmark releases. Done means compatible upgrades no longer require relinking solely because the project version changed, while incompatible ABI changes still receive an appropriate major version.