Fine with me either way. The earlier we release something, the better, for me ;-)
Gary On Jan 29, 2018 16:20, "Remko Popma" <remko.po...@gmail.com> wrote: > Any feedback on the idea to cut a branch from commit 21bc3aa and release > 2.11 from that branch? > > In the release notes we can announce that the next release will have > internal classes moved and packages renamed so future releases will have > binary compatibility issues. > > To me it makes sense to therefore name the next release 3.0 to signal this > incompatibility to users. > > Having a 3.0 release doesn’t necessarily mean we immediately start > requiring Java 8. That can could come in a subsequent release. > > > > On Tue, Jan 30, 2018 at 2:26 Remko Popma <remko.po...@gmail.com> wrote: > > > 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 <ralph.go...@dslextreme.com > > > > 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 <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 > >> > >> > >> > > >
