I’ve recently been looking at a super small DI library [1] which might be more
useful as a basis for the new DI system. If this logic is adaptable enough,
this could form the basis for a sort of pico-dependency-injection kernel. The
current code in master is more inspired by CDI which is a bit h
More than that, it has already taken too long. I’d like to support Java 11
fully.
Ralph
> On Jan 28, 2022, at 9:25 AM, Matt Sicker wrote:
>
> I’d imagine it’s because maintaining two active development branches for a
> long time is a pain in the ass.
> —
> Matt Sicker
>
>> On Jan 28, 2022, a
I’ve disabled the Jenkins build for Log4j2 as we’re already testing PRs via
GitHub right now. Unless we can use a GitHub Action to publish snapshots,
though, I’ll have to update our Jenkins build to simply do just that for the
master and release-2.x branches. I believe we’ve talked about this in
I’d imagine it’s because maintaining two active development branches for a long
time is a pain in the ass.
—
Matt Sicker
> On Jan 28, 2022, at 10:15, Gary Gregory wrote:
>
> What is the rush for releasing version 3?
>
> Gary
>
> On Fri, Jan 28, 2022, 10:05 Volkan Yazıcı wrote:
>
>> I think
I've said my bit, I'll wait for community consensus for now. Does changing
any of this requires a VOTE and if s, under what veto rules?
Gary
On Fri, Jan 28, 2022, 10:26 Volkan Yazıcı wrote:
> I totally agree with Carter's points.
>
> Given the current state of discussion, I propose the followin
What is the rush for releasing version 3?
Gary
On Fri, Jan 28, 2022, 10:05 Volkan Yazıcı wrote:
> I think such an SPI effort will not add a value enough to justify the delay
> it will cause for 3.0.0. We need to release `master`, preferably, ASAP,
> IMHO. Any "enhancements" can be scheduled for
See below
> On Jan 28, 2022, at 8:26 AM, Volkan Yazıcı wrote:
>
> I totally agree with Carter's points.
>
> Given the current state of discussion, I propose the following:
>
> - Every changes goes into a PR
+1
> - Merge requires a successful CI build
+1
> - Merge requires at least on
I totally agree with Carter's points.
Given the current state of discussion, I propose the following:
- Every changes goes into a PR
- Merge requires a successful CI build
- Merge requires at least one "approval"
Here "approval" can be fulfilled by following means:
- The committer h
I think such an SPI effort will not add a value enough to justify the delay
it will cause for 3.0.0. We need to release `master`, preferably, ASAP,
IMHO. Any "enhancements" can be scheduled for later releases, including
4.0.0.
For the record, I second Ralph's idea of pulling JsonReader up from
Jso
