Hi all, Note that the statement on the EOL site is incorrect:
"The reload4j project provides a drop-in replacement for Log4j 1.x with maintenance and security fixes." It certainly is not a "drop-in replacement" because it ripped out public classes and so breaks binary compatibility. It's more of a "use at your own risk of blowing up replacement". I really don't think we need to point to non-log4j projects on this page. Gary On Sat, Nov 16, 2024, 5:13 AM Piotr P. Karwasz <pi...@mailing.copernik.eu> wrote: > Hi Ralph, > > On 14.11.2024 06:50, Ralph Goers wrote: > > Log4j 2.3.x and 2.12.x don’t need votes. We declared that we were no > longer supporting Java 6 and then Java 7 and that those would be the last > releases to do so. We made an exception for Log4Shell and created patches > for both since the security exposure was so bad. Those release lines are > clearly marked as EOL and have been for a long time. > > Great! Does this mean I can remove the `/log4j/2.3.x` and > `/log4j/2.12.x` websites and redirect users to `/log4j/2.x`? More > specifically I could: > > * Add a "Levels of support" section to our support page[1] that > specifies what does terms like "Supported", "Security-only updates", > "End-of-Life" or "Dormant" mean. > > * Add a "Supported versions" section to the Log4j website, which > summarizes in tabular form the status of each development line. I am > thinking of something like on the Airflow website[2] or endoflife.date[3]. > > * Remove the `/log4j/2.3.x` and `/log4j/2.12.x` websites and redirect > them to `/log4j/2.x`. > > Piotr > > [1] https://logging.apache.org/support.html > > [2] > > https://airflow.apache.org/docs/apache-airflow/stable/installation/supported-versions.html > > [3] https://endoflife.date/log4j > >
