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