Here are my thoughts after working on several ASF projects for over 15 years.
Theoretically logging projects should follow the “release early, release often” philosophy. There are a few good reasons why it should be that way. However, when you have a project with very few committers with limited time following that can be easier said than done. Personally, I like to set a goal for what I would like to see in a next release and try to meet that. However, it is more important to have semi-frequent releases than to get everything you wanted in. Longer release cycles typically make people try to cram more in at the end because they know it will be a long time until the next one. This can lead to bugs being introduced or designs not being well thought out. Releasing frequently avoids this and also provides immediate feedback on whether you are going down the right path with a new feature. Ralph > On Aug 3, 2020, at 4:49 PM, Robert Middleton <osfan6...@gmail.com> 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. > >> 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/ >
