It seems like a good idea to keep releasing alpha-beta-milestones (whatever we want to call these) for pre-3.0 for now. TBH, I've not even tried it in my work projects yet. I'd rather do that on a very recent alpha. It feels like our alpha1 is "old".
Gary On Mon, Nov 6, 2023, 4: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. > > 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 >
