Blow up -> become very large, not corrupted.
Gary
On Tue, Oct 24, 2023, 6:45 AM Volkan Yazıcı 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.]*
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
Considering I’m one of the only people who adds @since tags (or Javadocs in
general), I think we’ll need some tooling to help with this. In Jenkins, we had
some sort of script for this so that we could add “@since TODO” to new files,
and the script would replace them all before tagging a
Agreed, we should use `@since` tags. Though this doesn't warrant a new
website folder for each release, does it? Given we never disclosed these
folders, I want to understand the value it delivered in the past that can't
be achieved if we switch to using a single folder.
On Mon, Oct 23, 2023 at
Hi Volkan,
On Mon, 23 Oct 2023 at 10:40, Volkan Yazıcı wrote:
>
> > it [doesn't] fully documents what was in prior releases
>
> Why is this a problem? We document newly added features with "starting from
> version X, Log4j ships Y...". Doesn't this address your concern?
I prefer to document
> it [doesn't] fully documents what was in prior releases
Why is this a problem? We document newly added features with "starting from
version X, Log4j ships Y...". Doesn't this address your concern?
Many projects follow this convention, even Java itself:
I am ok with 1 and 2, but not 3. Doing that means older releases web sites are
no longer available. Just because the latest includes release notes for all
versions doesn’t mean it fully documents what was in prior releases. However, I
am not surprised you are suggesting this as I posted in an
Hi Volkan,
On Sun, 22 Oct 2023 at 22:20, Volkan Yazıcı wrote:
>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
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
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`
- ...
10 matches
Mail list logo
