Blow up -> become very large, not corrupted. Gary
On Tue, Oct 24, 2023, 6:45 AM Volkan Yazıcı <vol...@yazi.ci> wrote: > Let me elaborate on what I want to achieve with CI automation. > > *[I will focus on Log4j, but my statements apply to other Maven-based > products as well; Log4j Tools, Log4j Kotlin, etc.]* > > 1. When a new Log4j `release/A.B.C` branch is detected, `logging > *-log4j-A_B_C.staged*.apache.org` will be automatically populated using > `./mvnw site` > 2. When a new Log4j release of version `A.B.C` is detected, ` > logging.apache.org*/log4j/A.B.C*` will be automatically populated using > `./mvnw site` > 3. When a change in `A.x` branch is detected, `logging.apache.org > */log4j/A.x*` will be automatically populated using `./mvnw site > -Drevision=A.B.C`, where `A.B.C` will be determined at runtime as the > latest published release of major version `A` > > #2, I initially didn't want to. Though had calls with Piotr, Ralph, Gary, > and Matt yesterday, and decided to keep that. #2 causes the Git repository > to blow up. Matt had some tips, I will propose a workaround soon. > > On Mon, Oct 23, 2023 at 1:38 PM Christian Grobmeier <grobme...@apache.org> > wrote: > > > 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` > <http://logging.apache.org/log4j> > > <http://logging.apache.org/log4j> will > > > redirect to `logging.apache.org/log4j/latest` > <http://logging.apache.org/log4j/latest> > > <http://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. > > >