`heif_version.h` should be removed
farindk opened this issue · comments
Exposing the version number in the public header heif_version.h is problematic. Client programs might assume that this is the currently installed version, while it is just the libheif version that the client was compiled against. The actually installed libheif version will often be different.
Version information should be exclusively obtained through heif_get_version() and related functions.
Removing this file entirely might break the build process of some clients that erroneously used this file for version information, but it does technically not break binary compatibility. That means, we should be able to remove it even in a minor version upgrade (upcoming v1.18.0).
Any objections to that?
I wouldn't call the change of the second version in the case of libheif a minor one, because often there are so many changes that it looks more like a semi-major version.
There are especially many changes in the build process, so I don’t see any problem removing
#include <libheif/heif_version.h>
It is a less breakable change than moving some functions from "libheif.h" to different files, imho.
It is a less breakable change than moving some functions from "libheif.h" to different files, imho.
I don't think anything got moved (at least, not anything in a released version). Stuff got added to different files (e.g. regions API), but those should still be included when libheif.h is included.
Exposing the version number in the public header
heif_version.his problematic. Client programs might assume that this is the currently installed version, while it is just the libheif version that the client was compiled against. The actually installed libheif version will often be different.
I think there are two uses:
- compiling, when its easier to check for a version than a function
- runtime, when its probably mostly for display
Ideally compilation would be against the pkg-config info if a version was needed, but I can understand why that might not be used (e.g. on windows, where its not well supported).
Version information should be exclusively obtained through
heif_get_version()and related functions.
I agree that is good for runtime information.
Removing this file entirely might break the build process of some clients that erroneously used this file for version information, but it does technically not break binary compatibility. That means, we should be able to remove it even in a minor version upgrade (upcoming v1.18.0).
I think its a public symbol, so removing it could well break compile-time compatibility. It wouldn't break runtime compatibility.
I think there are two uses:
compiling, when its easier to check for a version than a function
The problem is that this information from the header is effectively useless because it says nothing about the library version that is installed. It could be a later or even an earlier version.
Often, the library version will be in sync with the header during compilation of the client program, but will be replaced during the life-time of the application.
The problem is that this information from the header is effectively useless because it says nothing about the library version that is installed. It could be a later or even an earlier version.
Its valid at compile time (assuming the build environment is vaguely consistent - agree all bets are off if not).
Replacing libheif with an earlier minor version is not a compatible change, and will likely fail. Version numbers of any sort probably won't save you in C/C++. A later major version could have the same problems.
Replacing libheif with a later minor version should be OK.
As others already commented, it's helpful at compile-time, so you can use the version from the header to check if given APIs are available in libheif without having to rely on testing through autoconf or other means.
See
libheif/examples/encoder_png.cc
Line 102 in 3ebec35
libheif/examples/decoder_jpeg.cc
Line 220 in 3ebec35
I would rather keep it.
Agreed. We keep it.