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.

I have no issue with removing anything/everything from downloads.apache.org 
<http://downloads.apache.org/> since they are all available from the archive 
sites. As it is we are encouraged by Infra to ONLY keep the latest release. 
Again, we treated 2.3.x and 2.12.x as special since they were the last versions 
for the target platform. But after all these years I can’t imagine why anyone 
would need to download them.

In the past we always added a banner to each site when it moved to dormant.

Ralph

> On Nov 13, 2024, at 8:14 AM, Piotr P. Karwasz <pi...@mailing.copernik.eu> 
> wrote:
> 
> Hi all,
> 
> Looking at our releases, as the appear on `projects.apache.org`[1], I think 
> that it is about time to clean up `downloads.apache.org`. I would propose to:
> 
> 1. Formally vote on the end-of-life of the Apache Extras for Apache log4j[2] 
> and Apache log4php[3] projects.
> 
> 2. Formally vote on the end-of-life of the Log4j 2.3.x[4] and 2.12.x[5] 
> branches.
> 
> 3. Remove all the release files of the distributions that reached 
> end-of-life. Users can always find those releases on `archive.apache.org`.
> 
> 4. Update the websites to clearly mark some projects as EOL or dormant with a 
> link to a clear definition of the terms. For me these terms mean:
> 
>     End-of-life: There will be no further releases. Security reports for 
> those projects/branches will not be accepted and those projects/branches will 
> not be checked against vulnerabilities.
> 
>     Dormant: Further releases are unlikely, unless users step in. Security 
> reports and security releases are handled normally. The project can be voted 
> EOL at any time with an X-month notice.
> 
> 5. We should update our DOAP files. My understanding is that each subproject 
> (Apache Log4j Tools, Apache Log4j Transform) should have its own DOAP file.
> 
> 6. Currently we place all sub-projects of Log4j directly in the `logging` 
> folder, but `archive.apache.org`[6] shows that it wasn't always this way. For 
> example `log4j-scala` used to be in `log4j/scala`. Which convention should we 
> use?
> 
> Piotr
> 
> [1] https://projects.apache.org/releases.html
> 
> [2] https://logging.apache.org/log4j/extras/
> 
> [3] https://logging.apache.org/log4php/
> 
> [4] https://logging.apache.org/log4j/2.3.x/
> 
> [5] https://logging.apache.org/log4j/2.12.x/
> 
> [6] https://archive.apache.org/dist/logging/
> 

Reply via email to