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.
My goal would be to get 2.11.0 out as quickly as possible. 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>> >>>>> >>>>> >>>> >> >> >>
