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

Reply via email to