On Jan 31, 2018 13:30, "Ralph Goers" <[email protected]> wrote:
Barring something I am unaware of I should be able to do it this weekend. Awesome! :-) Gary Ralph > On Jan 31, 2018, at 12:44 PM, Gary Gregory <[email protected]> wrote: > > On Tue, Jan 30, 2018 at 11:14 AM, Gary Gregory <[email protected]> > wrote: > >> >> >> On Jan 30, 2018 11:11, "Ralph Goers" <[email protected]> wrote: >> >> That is all true, but that doesn’t require creating a new 3.0 branch. Or >> maybe I misunderstood what you meant by your use of “label". Yes, master >> should be targeted at 3.0. Yes, the pom.xml files should reflect that. It >> may be a bit before we agree on what all that should be, but all work on >> master should be targeted at that as well as incorporating anything added >> to the release-2.x branch. >> >> >> I meant that master should have a POM version different from the 2.x >> branch which it now does. I made it 3.0.0 but it could be something else. >> >> >> My goal would be to get 2.11.0 out as quickly as possible. >> >> > Hi Ralph, any thoughts on timing? > > Gary > > >> >> That's music to my ears :-) >> >> Gary >> >> >> Ralph >> >>> On Jan 30, 2018, at 9:21 AM, Gary Gregory <[email protected]> >> wrote: >>> >>> On Tue, Jan 30, 2018 at 9:15 AM, Ralph Goers <[email protected] >>> >>> 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 <[email protected]> >>>> wrote: >>>>> >>>>> Should we label master 3.0? >>>>> >>>>> Gary >>>>> >>>>> On Jan 30, 2018 07:22, "Remko Popma" <[email protected]> wrote: >>>>> >>>>>> 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 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>> >>>> >>>> >> >> >> >>
