> On Nov 6, 2023, at 2:37 AM, Piotr P. Karwasz <piotr.karw...@gmail.com> wrote:
>
> 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.
I would disagree. Over the course of the last 5 years I would say that
committing to both has been the pattern when required at least 90% of the time.
>
> 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.
Well, this has been brought up for the last 2 years. Basic attempts have been
made to validate it but I have the sense no one is ever going to be 100%
confident. Personally, I don’t need to be. The few cases we miss will be caught
fairly quickly once the software is being used. Fixing them shouldn’t be very
hard.
>
>> 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.
I don’t disagree that real integration tests should be developed. I just don’t
see a need to wait for them before a GA release.
>
> 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.
I am against a GA release in its current state. Everyone is. But we have to
keep creating releases to get feedback. Personally, I don’t think we need too
many more to feel confident.
I am fine with meeting on Nov 12. But the set of tasks I have in mind are a) no
new features are required b) fix whatever bugs are reported c) test it
ourselves. Everything else is optional.
FWIW, I am on step c right now except Log4j isn’t the problem. I am trying to
upgrade to Spring 3 with Log4j 3 and the Spring upgrade isn’t simple.
Ralph
