libcmark uses full version number as major dylib version number

[ryandesign]

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.

[jgm]

Yes, I know this isn't good practice. We've been using a versioning scheme that links the cmark version to the commonmark spec version -- thus, cmark 0.29.X implements the spec version 0.29. So this major number actually has nothing to do with the API.

It would probably be a good idea to transition away from this practice, which was meant to be temporary until the spec hit 1.0....

[nwellnhof]

Also see #252

[ryandesign]

Also see #252

Ah yes, that appears to be the same thing.