logging-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache <ralph.go...@dslextreme.com>
Subject Re: [log4j] clarify "internal" vs exported packages in core - plugin API
Date Tue, 30 Jan 2018 09:45:08 GMT
That spot looks ok to me. Please make the branch

Sent from my iPad

> On Jan 29, 2018, at 10:43 PM, Remko Popma <remko.popma@gmail.com> wrote:
> 
> If you want I can create a “release-2.11” or “release-2.x” branch from that commit.

> 
> 
> 
>> On Jan 30, 2018, at 14:17, Remko Popma <remko.popma@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 <remko.popma@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
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>> 
>>> 



Mime
View raw message