> On Nov 4, 2023, at 00:08, Christian Grobmeier <grobme...@apache.org> wrote: > […] > > Agreed, the earlier, so better, but making Log4j 3.x GA "first thing next > year" seems to be quite of a rush.
After another beta release, I don’t think that’s a rush. It’s not like the entire ecosystem will upgrade all at once! > As far as I know, we still have changes in 2.x that are not in 3.x. Any missing changes are likely minor and can be included in 3.0.1 or 3.1.0. We can do a diff between branches more easily now that they’ve been somewhat reformatted when combined with `git diff -w` to ignore whitespace changes, and this can reveal relevant changes. I’ve looked at some of that recently, and it looks like there are pom.xml differences, but I wasn’t finding much relevant changes from the bits I sampled. > I heard we lack integration tests and parallel testing in 3.x is disabled. > This does not make me feel like a GA, but starting a longer beta phase. I was wondering why the 2.x branch builds faster than main, but that’s not a blocker for releases. >>>>> With flume, audit and the other stuff eating time, it will be hard to get >>>>> this done. >>>> >>>> Get what done? As far as I am concerned Log4j 3.x can go to beta now >>>> and GA the first of the year. There are no required features left, just >>>> stuff that would be nice to get done but can be done after the initial >>>> GA release. >>> >>> I'm talking about adding Flume to our project, adding the community, and >>> maintaining the new component. >> >> Up til now that is all pretty much me. I expect it will stay that way >> for a time, although Matt has indicated an interest in contributing. > > Yes, that time you don't have for 3.x Flume doesn’t require a massive rewrite or anything like that. In fact, it could probably use trimming down of some now irrelevant modules. >>> We have open security issues with log4j-audit, and log4j-server still needs >>> to be cleaned up. >> >> Log4j-Audit has no open security issues. It simply needs dependency >> updates. Please don’t conflate one with the other. > > Ok, great, yes, it is using dependencies with major security holes and does > not look maintained, yet it is promoted as a main product on our website. Did > we check if it is OK to deliver those dependencies? Upgrading does not seem > trivial, we haven't also even started. The audit web app thing is a single user application that you can realistically only run locally. It’s all offline software besides the API, and the API depends on Log4j API which can be overridden by the user. >> Others have expressed things they would like to do because it is a >> major release and so some end-user impact is allowable. But most, if >> not all, of the things I have seen proposed could be done post 3.0 GA. >> So no, it is not a requirement that they be addressed. For example, >> Matt did a lot of work on the DI system. It took him forever. None of >> it was required. It was/is very beneficial to do but it wasn’t required. > > Why do you bring up Matts work here? It seems unrelated. The biggest change we wanted for 3.x was related to JPMS support and beginning to break out a large portion of log4j-core into separate modules. That was completed a while back. I did work on a few iterations of the plugin system to transform it into a more generic DI system, but that’s largely an implementation detail that could have been done post-3.0 as it was designed to be backward-compatible (which itself took some finagling to figure out how to unify, but it’s fine now). There have been some things I’ve changed that should be done before 3.0, but those largely involved removal of deprecated code and some small changes to APIs (such as flattening of extension interfaces, removal of Serializable, removal of the generic parameter from Layout). We can do some additional passes for anything else that should be cleaned up before 3.0, but it’s not much. I’ve suggested that we annotate code around API compatibility guarantees, and we are using @InternalApi in main to mark things that shouldn’t be used as stable code (even if it’s unlikely to change over time). — Matt Sicker
