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