If are going to call it 3.0 I would have liked to cut a release before all this modularization work and then created a branch so we could maintain it if necessary.
Ralph > On Jan 29, 2018, at 10:04 AM, Gary Gregory <garydgreg...@gmail.com> wrote: > > On Mon, Jan 29, 2018 at 8:17 AM, Remko Popma <remko.po...@gmail.com> wrote: > >> If we are going to make breaking changes in this release it may be wise to >> also do any package renaming in this release to keep the disruption limited >> to a single release instead of multiple. >> >> Specifically, I propose we take this release to do all package renaming to >> clarify the difference between classes that are "internal" to Log4j core >> and should not be depended on, and packages that we intend to export when >> Log4j core becomes a Java 9 module. >> >> This likely means introducing new "internal" packages and moving classes >> and interfaces into these new packages. >> >> I believe this is in line with what Matt proposed a while ago as the plugin >> API for core. All classes and interfaces that are not in an >> "internal" package are safe to depend on and we commit to preserving binary >> compatibility for such packages. Everything in a package with "internal" in >> the name is subject to change. >> >> Should we aim to complete this work before the 2.11 release? >> > > That's OK with me, and at this point, even though log4j-core is not > log4j-api, I would consider calling the release 3.0. > > Gary
