On Tue, Feb 6, 2024 at 5:46 PM Ralph Goers <ralph.go...@dslextreme.com> wrote:
> When you say “hard to work with it” what does that mean? Git commands work slow (e.g., `git status` takes seconds) and it is difficult to understand what goes where. > Volkan has mentioned some ideas to me which would allow us to keep the > relevant info from previous releases. > > I don’t like the idea of having multiple efforts going on. > Piotr implements the `1.x`, `2.x`, `3.x` scheme I proposed earlier. Though I still think Log4j 1, Log4j 2, and Log4j 3 websites should be moved to the `logging-log4j2` repository and `logging-log4j-site` repository should only be used for stuff that doesn't belong to a particular project repository, e.g., `log4j-extras` (since the original `log4j-extras` repository is converted to be read-only, we cannot move its website there) and `/xml/ns/changelog`. Nevertheless, Piotr's proposal can be a good first step in the direction I proposed earlier. Regarding keeping the website+manual of the old releases (e.g., `/log4j/log4j-2.19.0`, `/log4j/log4j-2.20.0`) without ending up in a state which we currently are... This is doable. We can place, say, `log4j-2.22.1` folder to a `asf-site-log4j-2.22.1` branch with its own `.asf.yaml` targeting the output to `/log4j/log4j-2.22.1`. Though... should we? I can see the use cases for wanting to keep the website+manual of every single release in a dedicated directory. Though my counter arguments are: 1. These pages were never officially linked, hence were not exposed to users. What is the pressing need right now to make this happen? 2. They get search engines confused and cause users to end up in legacy pages. 3. The infrastructure to realize this (putting each release to a separate site branch) is cumbersome, difficult to navigate for developers, deviates from the standard the rest of our websites follow, and hence complicates the release process substantially. 4. We (almost) never break backward compatibility in a major release line. Hence, the docs of `2.x` is a superset of the docs of, say, `2.22.0`. We also always document newly added features as "Starting from version `2.22.0`, ..." Given these, I don't see a compelling point of having a separate website for `2.22.0`. In short, 1. Release-specific website+manual (i.e., `/log4j/log4j-2.19.0`) was never an official service 2. It is difficult to implement and wrap automation around it 3. We can postpone it to a time where a need arises
