Ok, I reread the OP -- the breaking changes would be implementation details like jars and minimum JDK dependencies...
I always default to using major version changes as an opportunity to standardize things like lambda interfaces, clear up old cruft such as (now) unnecessary API methods, and so forth. However, for a project as widely used as log4j2, I can see how the equation is a bit different, and agree that maintaining API compat has compelling advantages. Regards, Raman On Mon, Dec 16, 2019 at 2:59 PM Raman Gupta <[email protected]> wrote: > > What is the point of releasing log4j 3.x if you only intend to make > non-breaking changes? Is it just a marketing thing then? > > On Mon, Dec 16, 2019 at 2:53 PM Ralph Goers <[email protected]> > wrote: > > > > > > > > > On Dec 16, 2019, at 12:41 PM, Gary Gregory <[email protected]> wrote: > > > > > > You cannot control "stratification" any more than how people architect > > > their apps ;-) It's just the nature of the success Java's tooling like > > > Maven that allows people to put together apps based on transitive > > > dependencies. The unintended consequence being jar hell. > > > > > > > I don’t get the point of this message. There are certainly things we cannot > > control and things we can control. Backwards compatibility of our code is > > one of the things we can control. > > > > Ralph > > > >
