You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Remko Popma <re...@gmail.com> on 2018/01/29 15:17:28 UTC
[log4j] clarify "internal" vs exported packages in core - plugin API
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?
Re: [log4j] clarify "internal" vs exported packages in core - plugin API
Posted by Gary Gregory <ga...@gmail.com>.
Fine with me either way. The earlier we release something, the better, for
me ;-)
Gary
On Jan 29, 2018 16:20, "Remko Popma" <re...@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 <re...@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.goers@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 <ga...@gmail.com>
> >> wrote:
> >> >
> >> > On Mon, Jan 29, 2018 at 8:17 AM, Remko Popma <re...@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
> >>
> >>
> >>
> >
>
Re: [log4j] clarify "internal" vs exported packages in core - plugin API
Posted by Gary Gregory <ga...@gmail.com>.
On Jan 31, 2018 13:30, "Ralph Goers" <ra...@dslextreme.com> 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 <ga...@gmail.com> wrote:
>
> On Tue, Jan 30, 2018 at 11:14 AM, Gary Gregory <ga...@gmail.com>
> wrote:
>
>>
>>
>> On Jan 30, 2018 11:11, "Ralph Goers" <ra...@dslextreme.com> 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 <ga...@gmail.com>
>> wrote:
>>>
>>> On Tue, Jan 30, 2018 at 9:15 AM, Ralph Goers <ralph.goers@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 <ga...@gmail.com>
>>>> wrote:
>>>>>
>>>>> Should we label master 3.0?
>>>>>
>>>>> Gary
>>>>>
>>>>> On Jan 30, 2018 07:22, "Remko Popma" <re...@gmail.com> wrote:
>>>>>
>>>>>> I created branch "release-2.x".
>>>>>>
>>>>>> On Tue, Jan 30, 2018 at 6:45 PM, Apache <ra...@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 <re...@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 <re...@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.goers@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 <re...@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.popma@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.goers@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 <
>>>>>> garydgregory@gmail.com
>>>>>>>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Jan 29, 2018 at 8:17 AM, Remko Popma <
>>>>>>> remko.popma@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
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>>
Re: [log4j] clarify "internal" vs exported packages in core - plugin
API
Posted by Ralph Goers <ra...@dslextreme.com>.
Barring something I am unaware of I should be able to do it this weekend.
Ralph
> On Jan 31, 2018, at 12:44 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> On Tue, Jan 30, 2018 at 11:14 AM, Gary Gregory <ga...@gmail.com>
> wrote:
>
>>
>>
>> On Jan 30, 2018 11:11, "Ralph Goers" <ra...@dslextreme.com> 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 <ga...@gmail.com>
>> wrote:
>>>
>>> On Tue, Jan 30, 2018 at 9:15 AM, Ralph Goers <ralph.goers@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 <ga...@gmail.com>
>>>> wrote:
>>>>>
>>>>> Should we label master 3.0?
>>>>>
>>>>> Gary
>>>>>
>>>>> On Jan 30, 2018 07:22, "Remko Popma" <re...@gmail.com> wrote:
>>>>>
>>>>>> I created branch "release-2.x".
>>>>>>
>>>>>> On Tue, Jan 30, 2018 at 6:45 PM, Apache <ra...@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 <re...@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 <re...@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.goers@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 <re...@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.popma@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.goers@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 <
>>>>>> garydgregory@gmail.com
>>>>>>>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Jan 29, 2018 at 8:17 AM, Remko Popma <
>>>>>>> remko.popma@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
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>>
Re: [log4j] clarify "internal" vs exported packages in core - plugin API
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Jan 30, 2018 at 11:14 AM, Gary Gregory <ga...@gmail.com>
wrote:
>
>
> On Jan 30, 2018 11:11, "Ralph Goers" <ra...@dslextreme.com> 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 <ga...@gmail.com>
> wrote:
> >
> > On Tue, Jan 30, 2018 at 9:15 AM, Ralph Goers <ralph.goers@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 <ga...@gmail.com>
> >> wrote:
> >>>
> >>> Should we label master 3.0?
> >>>
> >>> Gary
> >>>
> >>> On Jan 30, 2018 07:22, "Remko Popma" <re...@gmail.com> wrote:
> >>>
> >>>> I created branch "release-2.x".
> >>>>
> >>>> On Tue, Jan 30, 2018 at 6:45 PM, Apache <ra...@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 <re...@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 <re...@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.goers@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 <re...@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.popma@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.goers@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 <
> >>>> garydgregory@gmail.com
> >>>>>>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Mon, Jan 29, 2018 at 8:17 AM, Remko Popma <
> >>>>> remko.popma@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
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>
> >>
> >>
>
>
>
>
Re: [log4j] clarify "internal" vs exported packages in core - plugin API
Posted by Gary Gregory <ga...@gmail.com>.
On Jan 30, 2018 11:11, "Ralph Goers" <ra...@dslextreme.com> 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.
That's music to my ears :-)
Gary
Ralph
> On Jan 30, 2018, at 9:21 AM, Gary Gregory <ga...@gmail.com> wrote:
>
> On Tue, Jan 30, 2018 at 9:15 AM, Ralph Goers <ra...@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 <ga...@gmail.com>
>> wrote:
>>>
>>> Should we label master 3.0?
>>>
>>> Gary
>>>
>>> On Jan 30, 2018 07:22, "Remko Popma" <re...@gmail.com> wrote:
>>>
>>>> I created branch "release-2.x".
>>>>
>>>> On Tue, Jan 30, 2018 at 6:45 PM, Apache <ra...@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 <re...@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 <re...@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 <ra...@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 <re...@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 <re...@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.goers@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 <
>>>> garydgregory@gmail.com
>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Jan 29, 2018 at 8:17 AM, Remko Popma <
>>>>> remko.popma@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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>
>>
>>
Re: [log4j] clarify "internal" vs exported packages in core - plugin
API
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <ga...@gmail.com> wrote:
>
> On Tue, Jan 30, 2018 at 9:15 AM, Ralph Goers <ra...@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 <ga...@gmail.com>
>> wrote:
>>>
>>> Should we label master 3.0?
>>>
>>> Gary
>>>
>>> On Jan 30, 2018 07:22, "Remko Popma" <re...@gmail.com> wrote:
>>>
>>>> I created branch "release-2.x".
>>>>
>>>> On Tue, Jan 30, 2018 at 6:45 PM, Apache <ra...@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 <re...@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 <re...@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 <ra...@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 <re...@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 <re...@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.goers@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 <
>>>> garydgregory@gmail.com
>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Jan 29, 2018 at 8:17 AM, Remko Popma <
>>>>> remko.popma@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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>
>>
>>
Re: [log4j] clarify "internal" vs exported packages in core - plugin API
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Jan 30, 2018 at 9:15 AM, Ralph Goers <ra...@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 <ga...@gmail.com>
> wrote:
> >
> > Should we label master 3.0?
> >
> > Gary
> >
> > On Jan 30, 2018 07:22, "Remko Popma" <re...@gmail.com> wrote:
> >
> >> I created branch "release-2.x".
> >>
> >> On Tue, Jan 30, 2018 at 6:45 PM, Apache <ra...@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 <re...@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 <re...@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 <ra...@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 <re...@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 <re...@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.goers@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 <
> >> garydgregory@gmail.com
> >>>>
> >>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> On Mon, Jan 29, 2018 at 8:17 AM, Remko Popma <
> >>> remko.popma@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
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>
> >>>
> >>>
> >>
>
>
>
Re: [log4j] clarify "internal" vs exported packages in core - plugin
API
Posted by Ralph Goers <ra...@dslextreme.com>.
Why?
Ralph
> On Jan 30, 2018, at 8:15 AM, Gary Gregory <ga...@gmail.com> wrote:
>
> Should we label master 3.0?
>
> Gary
>
> On Jan 30, 2018 07:22, "Remko Popma" <re...@gmail.com> wrote:
>
>> I created branch "release-2.x".
>>
>> On Tue, Jan 30, 2018 at 6:45 PM, Apache <ra...@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 <re...@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 <re...@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 <ra...@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 <re...@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 <re...@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.goers@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 <
>> garydgregory@gmail.com
>>>>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> On Mon, Jan 29, 2018 at 8:17 AM, Remko Popma <
>>> remko.popma@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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>
>>>
>>>
>>
Re: [log4j] clarify "internal" vs exported packages in core - plugin API
Posted by Gary Gregory <ga...@gmail.com>.
Should we label master 3.0?
Gary
On Jan 30, 2018 07:22, "Remko Popma" <re...@gmail.com> wrote:
> I created branch "release-2.x".
>
> On Tue, Jan 30, 2018 at 6:45 PM, Apache <ra...@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 <re...@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 <re...@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 <ra...@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 <re...@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 <re...@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.goers@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 <
> garydgregory@gmail.com
> > >
> > >>>>>> wrote:
> > >>>>>>>
> > >>>>>>> On Mon, Jan 29, 2018 at 8:17 AM, Remko Popma <
> > remko.popma@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
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>
> > >>>
> >
> >
> >
>
Re: [log4j] clarify "internal" vs exported packages in core - plugin API
Posted by Remko Popma <re...@gmail.com>.
I created branch "release-2.x".
On Tue, Jan 30, 2018 at 6:45 PM, Apache <ra...@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 <re...@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 <re...@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 <ra...@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 <re...@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 <re...@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.goers@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 <garydgregory@gmail.com
> >
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> On Mon, Jan 29, 2018 at 8:17 AM, Remko Popma <
> remko.popma@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
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>
> >>>
>
>
>
Re: [log4j] clarify "internal" vs exported packages in core - plugin API
Posted by Apache <ra...@dslextreme.com>.
That spot looks ok to me. Please make the branch
Sent from my iPad
> On Jan 29, 2018, at 10:43 PM, Remko Popma <re...@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 <re...@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 <ra...@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 <re...@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 <re...@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 <ra...@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 <ga...@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> On Mon, Jan 29, 2018 at 8:17 AM, Remko Popma <re...@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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>>
Re: [log4j] clarify "internal" vs exported packages in core - plugin API
Posted by Remko Popma <re...@gmail.com>.
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 <re...@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 <ra...@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 <re...@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 <re...@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 <ra...@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 <ga...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> On Mon, Jan 29, 2018 at 8:17 AM, Remko Popma <re...@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
>>>>>
>>>>>
>>>>>
>>>>
>>
>>
Re: [log4j] clarify "internal" vs exported packages in core - plugin API
Posted by Remko Popma <re...@gmail.com>.
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 <ra...@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 <re...@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 <re...@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 <ra...@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 <ga...@gmail.com>
>>>> wrote:
>>>>>
>>>>> On Mon, Jan 29, 2018 at 8:17 AM, Remko Popma <re...@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
>>>>
>>>>
>>>>
>>>
>
>
Re: [log4j] clarify "internal" vs exported packages in core - plugin
API
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <re...@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 <re...@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 <ra...@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 <ga...@gmail.com>
>>> wrote:
>>>>
>>>> On Mon, Jan 29, 2018 at 8:17 AM, Remko Popma <re...@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
>>>
>>>
>>>
>>
Re: [log4j] clarify "internal" vs exported packages in core - plugin API
Posted by Remko Popma <re...@gmail.com>.
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 <re...@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 <ra...@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 <ga...@gmail.com>
>> wrote:
>> >
>> > On Mon, Jan 29, 2018 at 8:17 AM, Remko Popma <re...@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
>>
>>
>>
>
Re: [log4j] clarify "internal" vs exported packages in core - plugin API
Posted by Remko Popma <re...@gmail.com>.
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 <ra...@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 <ga...@gmail.com>
> wrote:
> >
> > On Mon, Jan 29, 2018 at 8:17 AM, Remko Popma <re...@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
>
>
>
Re: [log4j] clarify "internal" vs exported packages in core - plugin
API
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <ga...@gmail.com> wrote:
>
> On Mon, Jan 29, 2018 at 8:17 AM, Remko Popma <re...@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
Re: [log4j] clarify "internal" vs exported packages in core - plugin API
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Jan 29, 2018 at 8:17 AM, Remko Popma <re...@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