search

strukturag / libheif

libheif is an HEIF and AVIF file format decoder and encoder.
Other
1.76k stars 302 forks source link

incompatible ABI change to enum heif_metadata_compression in 1.18.0+ #1387

Open rathann opened 2 hours ago

rathann commented 2 hours ago

Commit ebf6c61260307b0514c134232f79b006a8960b49 swapped the definitions of heif_metadata_compression_deflate (2 to 3) and heif_metadata_compression_unknown (3 to 2) in libheif/api/libheif/heif.h. This constitutes an ABI break, but there was no corresponding SONAME change.

Any software using the 'unknown' or 'deflate' enums is going to get the meaning of the enums flipped until they are rebuilt against the new version.

Adding new enums at the end of the enumerator list is not a problem, but having 'unknown' and 'deflate' values flipped probably is.

rathann commented 2 hours ago

Could you put the deflate and unknown enums back in the previous order?

bradh commented 1 hour ago

But changing it back again now would be another breaking change, right? So maybe just an SONAME bump.

kmilos commented 40 minutes ago

So maybe just an SONAME bump.

The problem there is that libheif doesn't really track this in a sensible way, i.e. you wouldn't want to bump the project version major number to 2.x just because if this?

https://github.com/strukturag/libheif/blob/2a764da6053f08b472f7127f8d95772e64ef015a/libheif/CMakeLists.txt#L155

libheif has been on SOVERSION 1 forever, with many breaking changes already...

kalev commented 29 minutes ago

I think I'd just do a quick 1.19.4 or 1.19.3.1 release and mention loudly in the release notes that it is ABI incompatible with broken 1.19.3 release (but compatible with older releases), and just leave it at that. It's only been a few days since 1.19.3 was released and I imagine most distributions have not had time to pick up the new release yet anyway.

As long as there is a big warning to not use 1.19.3, I think this should be a pragmatic solution.

Fedora for example was pondering updating to 1.19.3 and this is where @rathann noticed the enums mixup: https://src.fedoraproject.org/rpms/libheif/pull-request/7. For us, it would certainly be easier if the new release had same soname as 1.18.x - we wouldn't need to rebuild dependent packages then and coordinate rebuilds with rpmfusion, but either way works.

farindk commented 23 minutes ago

Nothing changed between 1.18.0 and 1.19.x. The commit above was between v1.17.0 and v1.18.0 and metadata compression was marked experimental at that time.

Thus, I don't think any action has to be taken.

kmilos commented 20 minutes ago

@kalev The change came in a while ago at 1.18.0, it's not just 1.19.3...

kalev commented 1 minute ago

Ahh, sorry, ignore what I said then :)