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 >> >> >> >
