Thank you very much Ralph for compiling this list. On Fri, Dec 24, 2021, at 17:47, Ralph Goers wrote: > 1. Create a README.md that publishes the projects EOL status and do > nothing else. > 2. Create a README.md that says the project is EOL and no further big > fixes or enhancements will be made but 1.2.18 was a special > circumstance. Perform ONLY the following work for 1.2.18: > a. Make the build work with a modern version of Maven. > b. Fix the Java version bug. > c. Fix CVE-2021-4104 (expanded to address all JNDI components) > d. Fix CVE-2019-17571 > The expectation is that the above would address the actual issues > and not just remove classes. > Do NOT perform a release of any kind. > 3. Option 2 but only perform a source release. > 4. Option 2 but perform a full release. > 5. Option 4 but allow development to continue, including bug fixes and > enhancements.
I am thinking option 1 is the best. We should improve log4j2 instead of wasting time to software which was last. updated in what, 2012? However, I can see that there is some users who want to fix serious issues because they have reasons. I would be fine with 2, if: - we clearly mark it EOL and tell this is a security patch for those who still couldn't upgrade - we promote to work on log4j2 bridge et al, if someone is willing to contribute, and helping writing migration guides - we allow all commits which makes the build easier and fixes (critical) issues. No more features which could lead to a version bump to 1.3, which is already taken by a failed attempt to upgrade I am OK with option 4. The build is to complicated for anybody outside the developer list to make it happen. If we upgrade, we need to help users further. Here is a new option. Assuming we can make it a 1.2.18 and assuming we find out there is >=2 people willing to develop this further by ~mid 2022, we vote again if we continue this project. Only with a committed community we don't have to close it down again. Please take also in mind, that there is a competing logging project which developed the 1.2.x code base further. This will also add tensions. Cheers Christian > > I personally can see valid reasons to do any of the above. I have my > own opinion on this but I will post that in a reply to this discussion > kickoff. > > If you have other proposals feel free to state them. > > This discussion will be followed up by a vote thread if necessary. > > Ralph
