Then we need to add back the methods that were removed before a release can be
performed.
Ralph
> On Dec 30, 2020, at 5:40 PM, Gary Gregory wrote:
>
> On Wed, Dec 30, 2020 at 6:50 PM Ralph Goers
> wrote:
>
>> I should add that I am fine with getting rid of "2" interfaces that are
>> only use
On Wed, Dec 30, 2020 at 6:50 PM Ralph Goers
wrote:
> I should add that I am fine with getting rid of "2" interfaces that are
> only used by users who are implementing their own customizations. We can
> document that. I'm also ok with getting rid of Supplier if we can show that
> no code change or
I should add that I am fine with getting rid of "2" interfaces that are only
used by users who are implementing their own customizations. We can document
that. I'm also ok with getting rid of Supplier if we can show that no code
change or compilation is required. I don't know if that is true wit
Changing package names would require every user of the Log4j API to have to
change their code. We are not going to do that to our users. That is one of the
reasons folks have stuck with Log4j 1.x for so long. I would be -1 on any
changes that require that.
Ralph
> On Dec 30, 2020, at 2:47 PM,
Well. we should clean up our APIs now that we are on Java 8 and probably
11. For example, delete org.apache.logging.log4j.util.Supplier and use
java.util.function.Supplier. Fold all interfaces and classes postfixed with
"2" into their superclass. All of this will break BC which is what a major
vers
We would only need to do that if the versions are incompatible. Maven won’t let
you have two versions of log4j-api or log4j-core.
Ralph
> On Dec 30, 2020, at 1:02 PM, Gary Gregory wrote:
>
> Another thing for 3.0 is when to change the package name so you can have
> 2.x and 3.x in the same cla
Deprecation notice is indeed necessary. What needs to be done? Can I help
there?
Though this needs to be a team decision, right? All in all, count me in.
On Wed, Dec 30, 2020 at 8:47 PM Ralph Goers
wrote:
> If we are going to deprecate them we need to announce that in the next
> release. I kno
Another thing for 3.0 is when to change the package name so you can have
2.x and 3.x in the same class loader without things blowing left and right.
Just like you can have 1.x and 2.x at the same time.
Gary
On Wed, Dec 30, 2020, 14:47 Ralph Goers wrote:
> If we are going to deprecate them we ne
If we are going to deprecate them we need to announce that in the next release.
I know JSONLayout is being used because we have people complain about it. If
we do that we should have at least 6 months before 3.0 is released and 2.x and
3.0 are going to both be active for a while.
Ralph
> On
My motivation for dropping these modules are not merely due to the new
JsonTemplateLayout, though rather reducing the maintenance burden. I
"hypothesise" they are not used. For one, I cannot imagine a single use
case for YAML layout. Second, AbstractJacksonLayout renders stack traces in
a nested fa
They already are in master. If you will notice Volkan is talking about removing
those modules.
Ralph
> On Dec 30, 2020, at 7:54 AM, Matt Sicker wrote:
>
> I think the Jackson layouts could at least be separated from core,
> especially since they require dependencies to function.
>
> On Tue, 2
I think the Jackson layouts could at least be separated from core,
especially since they require dependencies to function.
On Tue, 29 Dec 2020 at 21:38, Ralph Goers wrote:
>
> Volkan, I am fine with deleting those modules however that would require that
> you make sure that you replace the exist
Guten Tag Robert Middleton,
am Mittwoch, 30. Dezember 2020 um 15:18 schrieben Sie:
> I also have a separate branch for the documentation updates, which
> should be ready at this point.
Then let's have a look at this one first.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning
AM
> I'm using C++Builder 10.2 with the legacy compiler currently, that
> surely doesn't support C++14 or 17. So what should I test? Do you want
> to create a DRAFT-PR on GitHub or tell me some special branch in your
> fork or ...? The DRAFT seems like the easiest approach.
Sure, I'll do that in a li
Guten Tag Robert Middleton,
am Dienstag, 29. Dezember 2020 um 23:54 schrieben Sie:
> I would be curious to know how things work for you. I think that I've
> avoided a lot of the C++14 and C++17 features, but some may have snuck
> in(although from looking at the Embarcadero wiki any recent version
15 matches
Mail list logo
