I would like to do the Log4j `2.22.0` release in a couple of days;
there are some bug fixes and SBOM is ready to be shipped. Let me know
if you have objections.
Go for it and thank you!
Gary
On Mon, Nov 13, 2023, 9:24 AM Volkan Yazıcı wrote:
> I would like to do the Log4j `2.22.0` release in a couple of days;
> there are some bug fixes and SBOM is ready to be shipped. Let me know
> if you have objections.
>
That is OK with me. T
Ralph
> On Nov 13, 2023, at 7:22 AM, Volkan Yazıcı wrote:
>
> I would like to do the Log4j `2.22.0` release in a couple of days;
> there are some bug fixes and SBOM is ready to be shipped. Let me know
> if you have objections.
After some discussions yesterday about what’s up for 3.0 (notes are somewhere),
I wanted to share the list of action items I'm planning to implement in main:
* Removal of legacy OSGi support. We will rely on ServiceLoader and things like
SPI Fly or other common OSGi mechanisms for supporting Ser
Go for it! I love how streamlined our release process is now. :)
—
Matt Sicker
> On Nov 13, 2023, at 08:22, Volkan Yazıcı wrote:
>
> I would like to do the Log4j `2.22.0` release in a couple of days;
> there are some bug fixes and SBOM is ready to be shipped. Let me know
> if you have objections
Hi Matt,
On Mon, 13 Nov 2023 at 19:18, Matt Sicker wrote:
> * Removal of legacy OSGi support. We will rely on ServiceLoader and things
> like SPI Fly or other common OSGi mechanisms for supporting ServiceLoader
> while deferring lower level OSGi integration to libraries like Pax-Logging.
We mu
Hi all,
As you probably noticed, all our packages (at least the exported ones)
are annotated with the OSGi annotation `@Version`.
This might result in failures from the `bnd-baseline-maven-plugin` if
you make changes in the public API without incrementing the version
annotation.
Since BND only in
How does this relate, if at all, to the COMPATIBLE_API_VERSIONS constant
defined in ProviderUtil.java? We use that to ensure the API only binds with a
compatible implementation of the API.
Ralph
> On Nov 13, 2023, at 1:29 PM, Piotr P. Karwasz wrote:
>
> Hi all,
>
> As you probably noticed, a
This is a lazy-vote to release the Apache Logging Parent 10.4.0.
Website: https://logging.staged.apache.org/logging-parent
GitHub: https://github.com/apache/logging-parent
Commit: e45457c683302242be5e8e7c3c33edf8f0e0ec0e
Distribution: https://dist.apache.org/repos/dist/dev/logging/logging-parent
N
Hi Ralph,
On Mon, 13 Nov 2023 at 22:18, Ralph Goers wrote:
>
> How does this relate, if at all, to the COMPATIBLE_API_VERSIONS constant
> defined in ProviderUtil.java? We use that to ensure the API only binds with a
> compatible implementation of the API.
It is certainly related, although in p
It’s similar to the compatible API versions, but the BND equivalent here would
be the highest package version of all the packages in log4j-api (since the
packages don’t get split out from the modules in practice).
—
Matt Sicker
> On Nov 13, 2023, at 16:02, Piotr P. Karwasz wrote:
>
> Hi Ralph,
The version number only changes when we intentionally change the API so that it
would cause failures with an older implementation. For example, I believe the
last time it changed was when we introduced ServiceLoader to locate the
implementation.
In 3.x the constant is set to 3.0.0 as the Log4j
12 matches
Mail list logo
