I believe there is confusion here as to what level of compatibility requirements we set at the release of 3.0.0. Some remaining changes proposed for 3.x are technically breaking changes depending on the level of API stability in question. Personally, I think we should demarcate what APIs are truly stable public APIs and which ones are not, but we do a fairly good job of that with the API module itself at least (which is not where any of the proposed breaking changes happen to be as far as I know).
I do have experience working in codebases where backward compatibility is demanded above all else (Jenkins mainly, though our own API here is similar), so it’s not like I’m against it. However, I think it’s important to be realistic about what that API compatibility guarantee is, especially if you don’t already have some sort of stable meta-API like Linux does with system calls (which is itself a unique implementation detail). — Matt Sicker > On Nov 2, 2023, at 21:36, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > > >> On Nov 2, 2023, at 10:30 AM, Christian Grobmeier <grobme...@apache.org> >> wrote: >> >> >> >> On Thu, Nov 2, 2023, at 17:04, Gary Gregory wrote: >>> Log4j 3 matching Spring 3 seems obviously a good thing to me. Going to Java >>> 17 seems to me as well a good thing. >>> >>> Gary >>> >>> On Thu, Nov 2, 2023, 7:04 AM Ralph Goers <ralph.go...@dslextreme.com> wrote: >>> >>>> I should add that I am concerned that we are missing a huge opportunity >>>> with Spring 3. A lot of folks will start their migration to Spring 3 early >>>> next year. Tying Log4J 3.x to that is a big opportunity for people to >>>> upgrade at the same time. >> >> If this is the case, then how would we achieve the goal of releasing it >> together? > > Releasing what together? Spring Boot 3 is already GA. It is using Log4j 2.x > currently. However, with Log4j 3.x targeting Java 11 and 17 (Spring Boot 3 > requires Java 17) it will be a better choice for most users. I would also not > be surprised to see Spring Boot update their dependencies to use Log4j 3.x at > some point since they won’t require any code changes. > >> >> 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. > >> >> This workload is too much for this handful of people. Removing load was btw >> also the idea of retiring components, so we can spend this time on other >> things of interest > > Again, I don’t know to what workload you are referring. > >> >> I would like to suggest that we have a team call soon where we collect our >> ideas of how we can reach that and refresh our shared vision. > > I’m pretty much always up for a team call. > >> >> Btw what is meant with spring 3? Spring boot is 3.1.15 already, spring >> framework is 6.x. > > Spring Boot 3.x > > Ralph
