I think it is OK to break compatibility in a major version. I can't believe we'd ship classes that are duplicates of Java classes like BiConsumer.
Gary On Mon, Oct 9, 2023, 4: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 >
