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. > Would be enough already if you would go through them and provide a > second opinion about which of those could easily be closed. I would > close ideas like APR database layer, CI-related stuff etc. most > likely. Additionally some very old 0.9.7-related issues. But that > keeps lots of other errors and improvements like new appenders. > Here's my quick run-through of issues currently in JIRA: LOG4CXX-490 - Should be easily fixable, but do we care about VS2015? LOG4CXX-483 - Issue was resolved; I will create some documentation if this comes up again though. LOG4CXX-481 - I'm not sure who is the responsible member for this. LOG4CXX-455 - This looks to still be an issue, although I'm not sure what the correct way to do it would be. Maybe we add a new check to also suppress exceptions? LOG4CXX-454 - VS2013 issue, can probably be closed at the moment. LOG4CXX-439 - Very old, not sure if still relevant at this point LOG4CXX-438 - Very old, not sure if still relevant at this point LOG4CXX-431 - Probably still an issue, but I think the best solution here is to document and have a callback function that gets called whenever a new thread starts, allowing the user to do their own signal handling(a default implementation would be good too). e.g. log4cxx::thread::setThreadStartFn --> called in new thread. LOG4CXX-398 - It looks like this has already been fixed? LOG4CXX-396 - Probably no longer relevant with CMAKE LOG4CXX-389 - Very old and not enough information LOG4CXX-384 - Very old and not enough information LOG4CXX-377 - Very old and not enough information LOG4CXX-374 - Very old and not correct usage of the library(using std::endl in logging operation) LOG4CXX-352 - Probably not an actual bug according to the comments LOG4CXX-345 - Very old and not enough information LOG4CXX-343 - Very old and not enough information LOG4CXX-341 - Very old and not enough information LOG4CXX-338 - Very old and not much activity, probably not an issue anymore LOG4CXX-335 - Who uses sun studio anymore? LOG4CXX-333 - Very old and likely not an issue LOG4CXX-309 - Very old, probably not a bug in log4cxx LOG4CXX-301 - Very old, probably best to close it out LOG4CXX-289 - Very old, who uses Solaris anymore? LOG4CXX-276 - Looks to be fixed LOG4CXX-274 - very old at this point, may no longer be an issue LOG4CXX-261 - Very old, who uses Solaris anymore? LOG4CXX-260 - should be fixed as of LOG4CXX-457 LOG4CXX-244 - Very old versions here, I don't see the point in keeping this open. LOG4CXX-205 - Very old issue, maynot be a problem LOG4CXX-101 - Very old issue, unless somebody has a specific need to use mysql this is almost certainly too old to be useful. LOG4CXX-61 - Unless APR has database support(it doesn't seem too) this should probably be closed LOG4CXX-1 - I would say we should close this; any SMTP support may or may not even work anymore There are a bunch of other old issues as well, but some of them at least have potentially enough information to do something with. -Robert Middleton [1]: https://semver.org/
