I agree with Ralph. We can still do this. Maybe we should start a 2.11 branch from an earlier commit, from before we started to rename packages, and cut a 2.11 release from that branch?
On Tue, Jan 30, 2018 at 2:08 AM, Ralph Goers <[email protected]> wrote: > 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 <[email protected]> > wrote: > > > > On Mon, Jan 29, 2018 at 8:17 AM, Remko Popma <[email protected]> > 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 > > >
