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