>so it’s really a straw man argument. Please. Log4j 1.x -> 2.x upgrade is no way seamless. I know lots of apps that do not need 2.x features, and that can't upgrade. That is they are stuck with 1.x.
>There is nothing stopping people from forking log4j and using their own fork A fork under io.github.vlsi.log4j:log4j would never be considered as "official", so it would never get traction. That is why I am trying to "fork" log4j within the ASF. Incubator: https://lists.apache.org/thread/mx667xg7rps5b7rhgr7pojmj26o9qzq7 Logging: https://lists.apache.org/thread/zsomx4qbmnwlcokpnvtywh07p33y55gh >The problem with making an official release that fixes 1.x.x is that you are officially supporting it >and you will be expected to support other changes I have no problems "officially supporting" log4j 1.x releases. If I run out of time, I am OK to transfer privileges to the ones who are eager to support it. >However I would suggest that it would be more valuable to use that time and >effort on making the current version better and encouraging/helping people to stop using the obsolete stuff. That does not work in practice. I believe, people value **predictability** over "new features". I am afraid a lot of people would continue using vulnerable 3.x, so I would just release 3.x. Vladimir
