Describe the feature
|
# We are not ABI stable yet |
indicates that
aws-c-compression is not yet ABI stable.
This request is for one (or both) of the following to be done:
- Appropriate SONAME updates when there are ABI changes (preferably limiting changes)
- A rather stable ABI and API so that consumers do not need to change very often.
We have a strong preference for shared libraries to use symbol versioning as this majorly helps in backwards and forwards compatibility across library and application versions.
Use Case
Being able to package software that uses aws-c-compression as a dependency to be included in Amazon Linux and other Linux distributions.
In order to be packaged for Linux distributions such as Amazon Linux, applications should use shared libraries, and not statically link their dependencies, especially if there are multiple applications with the same dependency.
https://github.com/awslabs/mountpoint-s3/ is one example of a package that has an aws-c-compression dependency that should be dynamically linked rather than statically, and a request for it to be packaged is fairly popular, see awslabs/mountpoint-s3#442
Proposed Solution
Immediate ask: aws-c-compression project adds ABI compatibility testing, and changes the SONAME of the shared library as needed.
Preferred solution: a decently stable ABI with a library using symbol versioning in order to enhance forwards and backwards compatibility.
This ask would include the dependencies of aws-c-compression as well.
Other Information
This is as much policy as it is any technical work. I can very much send PRs that enable some ABI compatibility checking and enabling symbol versioning, but setting the policy of the project to care about ABI compatibility is not something I can directly do, and must come from maintainers.
Acknowledgements
Describe the feature
aws-c-compression/CMakeLists.txt
Line 50 in f951ab2
aws-c-compressionis not yet ABI stable.This request is for one (or both) of the following to be done:
We have a strong preference for shared libraries to use symbol versioning as this majorly helps in backwards and forwards compatibility across library and application versions.
Use Case
Being able to package software that uses
aws-c-compressionas a dependency to be included in Amazon Linux and other Linux distributions.In order to be packaged for Linux distributions such as Amazon Linux, applications should use shared libraries, and not statically link their dependencies, especially if there are multiple applications with the same dependency.
https://github.com/awslabs/mountpoint-s3/ is one example of a package that has an
aws-c-compressiondependency that should be dynamically linked rather than statically, and a request for it to be packaged is fairly popular, see awslabs/mountpoint-s3#442Proposed Solution
Immediate ask:
aws-c-compressionproject adds ABI compatibility testing, and changes the SONAME of the shared library as needed.Preferred solution: a decently stable ABI with a library using symbol versioning in order to enhance forwards and backwards compatibility.
This ask would include the dependencies of
aws-c-compressionas well.Other Information
This is as much policy as it is any technical work. I can very much send PRs that enable some ABI compatibility checking and enabling symbol versioning, but setting the policy of the project to care about ABI compatibility is not something I can directly do, and must come from maintainers.
Acknowledgements