I think you are on the right track. We have to think of the main use case where a break in compatibility would cause a problem - an application uses libraries compiled with Log4j 2.x.
I am much less concerned about custom plugins as presumably the user has some control over them. That said, I would hope the vast majority of plugins from third parties would continue to work. We cannot put users in a position where they cannot upgrade until all their dependencies do. Note that Spring Boot builds with Log4j 2.x. It needs access to PerformanceSensitive, PropertiesUtil, and PropertySource. Ralph > On Oct 9, 2023, at 1:17 AM, Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > > Hi all, > > We have often declared that 3.x will **not** constitute a major > version for Log4j API and that everything that used to work with 2.x > will work with 3.x (even provider code). > > However that statement does not apply in practice, since some breaking > changes **were** introduced e.g. in the `util` subpackage (cf. [1] > e.g.), which is marked as internal, but: > * in practice it is often used by plugin providers, > * has some classes (like MessageSupplier) that are actually used by > consumers of the API. > > That is why I would propose to revise the statement about compatibility: > * the main,`message` and `status` packages should be 100% compatible > with the previous version, > * the `spi` package should be as much compatible as possible, > * the `simple` package should be internal and we can do with it > anything we please, > * the `util` package should keep the types used by other packages and > all other classes should be moved to `util.internal`. > > I made an experiment[2] to see how many classes we need to keep in > `util`. It turns out we just need to keep: > * BiConsumer, IndexedReadOnlyStringMap, MessageSupplier, > MultiFormatStringBuilderFormattable, ReadOnlyStringMap, > StringBuilderFormattable, Supplier and TriConsumer to prevent breaking > changes in the main and `message` packages, > * StringMap to prevent changes in the `spi` package, > * we could keep `Constants` to prevent some `2.x` plugins from breaking. > > What do you think? > > Piotr > > [1] https://github.com/apache/logging-log4j2/pull/1586 > [2] https://github.com/ppkarwasz/logging-log4j2/tree/clean-break
