On Jan 31, 2018 13:30, "Ralph Goers" 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 wrote:
>
> On Tue, Jan 30, 2018 at 11:14 AM, Gary Gregory
> wrote:
>
>>
>>
>> On Jan 30, 2018 11:11, "
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 wrote:
>
> On Tue, Jan 30, 2018 at 11:14 AM, Gary Gregory
> wrote:
>
>>
>>
>> On Jan 30, 2018 11:11, "Ralph Goers" wrote:
>>
>> That is all true, but that doesn’t r
On Tue, Jan 30, 2018 at 11:14 AM, Gary Gregory
wrote:
>
>
> On Jan 30, 2018 11:11, "Ralph Goers" 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 po
On Jan 30, 2018 11:11, "Ralph Goers" 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 w
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 mas
On Tue, Jan 30, 2018 at 9:15 AM, Ralph Goers
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-rele
Why?
Ralph
> On Jan 30, 2018, at 8:15 AM, Gary Gregory wrote:
>
> Should we label master 3.0?
>
> Gary
>
> On Jan 30, 2018 07:22, "Remko Popma" wrote:
>
>> I created branch "release-2.x".
>>
>> On Tue, Jan 30, 2018 at 6:45 PM, Apache
>> wrote:
>>
>>> That spot looks ok to me. Please make
Should we label master 3.0?
Gary
On Jan 30, 2018 07:22, "Remko Popma" wrote:
> I created branch "release-2.x".
>
> On Tue, Jan 30, 2018 at 6:45 PM, Apache
> wrote:
>
> > That spot looks ok to me. Please make the branch
> >
> > Sent from my iPad
> >
> > > On Jan 29, 2018, at 10:43 PM, Remko Pop
I created branch "release-2.x".
On Tue, Jan 30, 2018 at 6:45 PM, Apache 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 wrote:
> >
> > If you want I can create a “release-2.11” or “release-2.x” branch from
> that co
That spot looks ok to me. Please make the branch
Sent from my iPad
> On Jan 29, 2018, at 10:43 PM, Remko Popma 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 wrote:
>>
>> I think it’s possib
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 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/21bc3aa3bf8d8
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
(Th
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 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
Fine with me either way. The earlier we release something, the better, for
me ;-)
Gary
On Jan 29, 2018 16:20, "Remko Popma" 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 w
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 theref
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
wrote:
> If are going to call it 3.0 I would have liked to cut a
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 wrote:
>
> On Mon, Jan 29, 2018 at 8:17 AM, Remko Popma wrote:
>
>> If we ar
On Mon, Jan 29, 2018 at 8:17 AM, Remko Popma 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 releas
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
19 matches
Mail list logo
