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.
> >
>

Reply via email to