Why? Ralph
> On Jan 30, 2018, at 8:15 AM, Gary Gregory <garydgreg...@gmail.com> wrote: > > Should we label master 3.0? > > Gary > > On Jan 30, 2018 07:22, "Remko Popma" <remko.po...@gmail.com> wrote: > >> I created branch "release-2.x". >> >> On Tue, Jan 30, 2018 at 6:45 PM, Apache <ralph.go...@dslextreme.com> >> wrote: >> >>> That spot looks ok to me. Please make the branch >>> >>> Sent from my iPad >>> >>>> On Jan 29, 2018, at 10:43 PM, Remko Popma <remko.po...@gmail.com> >> wrote: >>>> >>>> If you want I can create a “release-2.11” or “release-2.x” branch from >>> that commit. >>>> >>>> >>>> >>>>> On Jan 30, 2018, at 14:17, Remko Popma <remko.po...@gmail.com> wrote: >>>>> >>>>> I think it’s possible to search for a commit hash in IntelliJ, but >> here >>> is a github link: >>>>> https://github.com/apache/logging-log4j2/commit/ >>> 21bc3aa3bf8d8a043459c6a58e774b82a617a058 >>>>> >>>>> LOG4J2-2225 provide alias for SystemMillisClock so the fully qualifie… >>>>> …d class name doesn't need to be published >>>>> >>>>> (This should be included, the next commit should be excluded. ) >>>>> >>>>> (Shameless plug) Every java main() method deserves >> http://picocli.info >>>>> >>>>>> On Jan 30, 2018, at 12:51, Ralph Goers <ralph.go...@dslextreme.com> >>> wrote: >>>>>> >>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>>> >>> >>> >>> >>
