Hi Ralph,

On Sun, 5 Nov 2023 at 05:39, Ralph Goers <ralph.go...@dslextreme.com> wrote:
> If we have changes in 2.x that are not in 3.x they aren’t many and we will 
> never find that out without releasing. In general users don’t want to use 
> alphas or betas. The alphas and betas are there so we can get feedback on 
> issues such as these but the majority of them won’t appear until a GA 
> release. To be clear, we MUST have one or two betas before a GA release 
> precisely because we WILL have issues to deal with. This is completely normal 
> and expected.

Looking at the commit pattern, changes to 2.x are not immediately
followed by changes to 3.x. This does not mean they are neve applied,
but it is hard to check if they were ever applied.

The easiest way to check for regressions is `git diff -w` as Matt
says, but this only makes sense after we reformat the code using a
deterministic formatter.

> Lack integration tests? Yes 2.x lacks integration tests and always has. Why 
> would we delay 3.x for something 2.x doesn’t have. All the integration tests 
> will prove is that various log4j modules can coexist together because some of 
> them use different dependencies. The unit tests are what matter and they by 
> and large pass. That said, I did make the request to create integration tests 
> because Gary has always been afraid of breaking Log4j into multiple repos 
> because he believes having everything compile and build together provides 
> assurance that everything will work together. If everything was using managed 
> depdendencies that would be true. But they don’t so it isn’t.

It's true, 2.x does not have integration tests or better, most unit
tests are in fact integration tests (they test the entire stack). The
tests are performed on the classpath, which is enough for 2.x.

However, the main feature of 3.x is JPMS. We can not possibly test
JPMS with tests that run on the classpath or in the same module as the
code being tested. We need real integration tests that use the module
path and test each optional dependency at a time.

Remark: I am against releasing 3.x in its current state, but I am
flexible on the amount of features required to release it. I second
Christian's proposal for a meeting on November 12th: if the PMC agrees
on a set of tasks required to release 3.x, I might convince my
employer to allow me to implement them as part of my job.

Piotr

Reply via email to