On Tue, Jan 30, 2018 at 9:15 AM, Ralph Goers <ralph.go...@dslextreme.com> wrote:
> Why? > We have a new branch for 2.11.0, it will/should build in Jenkins so it will populate the SNAPSHOT repository. Therefore, master needs a NEW SNAPSHOT version. I felt there was consensus on this ML that the reason we created the 2.x-release branch was that there were too many changes in master for 2.11.0 and that due to the modular work going on with BC-breaking changes in Core, this would warrant a major version change. Gary > 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 > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> > >>> > >>> > >>> > >> > > >
