I created branch "release-2.x".

On Tue, Jan 30, 2018 at 6:45 PM, Apache <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]>
> 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 <[email protected]>
> 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 <[email protected]>
> 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 <
> [email protected]>
> >>>>> 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 <[email protected]
> >
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> On Mon, Jan 29, 2018 at 8:17 AM, Remko Popma <
> [email protected]>
> >>>>>> 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
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>
> >>>
>
>
>

Reply via email to