On Mon, Aug 03, 2020 at 07:49:14PM -0400, Robert Middleton wrote: > Thorsten, > > > > A number of these are rather large changes, so it probably > > > doesn't make sense to work on them until there's a known-good release, as > > > they would likely break both API and ABI compatibility. > > > > Does it really matter much if things are broken now vs. with 0.12.0 or > > alike? Backwards compatibility was somewhat broken already when > > changing how the macros are implemented, when returning new LevelPtrs > > to fix threading-issues and with introducing CMAKE in favor of > > building with Maven+ANT. > > > > I have a few thoughts on that: > 1. Having a known-good release means that there should be more users, > helping to better test the library. > 2. It depends on the level of backwards-compatability breakage that > there is. For people like you who have a limited environment, having > a version that does not depend on new C++ features allows for a > 'legacy' version and a 'modern' version. > 3. Adopting a semver[1] versioning at some point would probably make > sense. If there's an API breakage that should be properly documented > as part of the versioning. Arguably since this is technically 0.11.0 > version it doesn't really matter, since major version 0 allows major > API breakage.
While the version is at 0.x.x, the at least the old auttools based build system declares SONAME to be 10 [1], so log4cxx is declaring a stable ABI/API. However, as said in an earlier thread, this is not a problem for a distribution (like Debian) as this is usual business to cope with ABI/API changes. (if it does not happen too ofthen, as a library transition means some work.) [1] The version currently in Debian: $objdump -p liblog4cxx.so | grep SONAME SONAME liblog4cxx.so.10 -- tobi
