This sounds pretty cool Volkan, if I didn't get anything I pretty much like it. One question - you wrote:
"we all will enjoy automatically populated Log4j websites." Does this mean we will see our website is updated automatically by CI so we can see in example /log4j/dev? Or what else is "automatically updated"? On Sun, Oct 22, 2023, at 22:20, Volkan Yazıcı wrote: > Currently, we have the following folder structure in the > `logging-log4j-site` repository for the Log4j project: > > - `log4j-1.2.17` – the website generated by the last Log4j 1 release, > i.e, `1.2.17` > - `log4j-1.2` – symlinks to `log4j-1.2.17` > - `1.x` – symlinks to `log4j-1.2.17` > - ... > - `log4j-2.19.0` – the website generated by the `2.19.0` release > - `log4j-2.20.0` – the website generated by the `2.20.0` release > - `log4j-2.21.0` – the website generated by the `2.21.0` release > - `2.x` – symlinks to `log4j-2.21.0` (the latest Log4j 2 release) > > I propose keeping existing folders as is (hence, *no changes to the > existing URLs!*) and applying following practices: > > 1. *Add a `latest` symlink* pointing to the latest stable version. Today > it will point to `2.x`, sometime in the future it will point to `3.x`. > - This will make following URLs possible: > https://logging.apache.org/log4j/latest > - This convention is practiced by several other projects, e.g., > Spring Boot: https://docs.spring.io/spring-boot/docs/current > 2. *Redirect root to `latest`*, i.e., `logging.apache.org/log4j` will > redirect to `logging.apache.org/log4j/latest` > 3. *Don't create a new folder for every release, but override the `2.x` > folder.* > - This is okay, since we keep backward compatibility in minor+patch > releases and explicitly provide version for features that are added > later > on (e.g., "starting from 2.17.0 Log4j provides X...") > - We can set up CI jobs to periodically populate `1.x`, `2.x`, `3.x`, > `4.x`, etc. websites and avoid the need to generate the website once and > for all. > - We will stop polluting the folder structure. > > As a matter of fact, I already implemented this convention for some > projects. All the following URLs work: > > - `logging-parent` > - logging.apache.org/logging-parent > - logging.apache.org/logging-parent/latest > - logging.apache.org/logging-parent/10.x > - `logging-log4j-kotlin` > - logging.apache.org/log4j/kotlin > - logging.apache.org/log4j/kotlin/latest > - logging.apache.org/log4j/kotlin/1.x > - `logging-log4j-scala` > - logging.apache.org/log4j/scala > - logging.apache.org/log4j/scala/latest > - logging.apache.org/log4j/scala/13.x > - `logging-log4j-tools` > - logging.apache.org/log4j/tools > - logging.apache.org/log4j/tools/latest > - logging.apache.org/log4j/tools/0.x > - `logging-log4j-transform` > - logging.apache.org/log4j/transform > - logging.apache.org/log4j/transform/latest > - logging.apache.org/log4j/transform/0.x > > Unless there are objections, I will update the CI in this direction and we > all will enjoy automatically populated Log4j websites.
