I agree in principal but I am having a hard time figuring out which commit that was.
Ralph > On Jan 29, 2018, at 4:19 PM, 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 >>> >>> >>> >>
