GitHub user ppkarwasz added a comment to the discussion: Roadmap for `2.25.1`
release
The vote to release **Apache Log4j 2.25.1** has started and will remain open
for **72 hours**. We invite the community to test the release candidate to help
ensure a stable and reliable release.
## How to
GitHub user ppkarwasz edited a discussion: Roadmap for `2.25.1` release
Hi everyone,
@vy and I had a call to discuss the aftermath of the `2.25.0` release. While
generally successful, we identified a few issues that affect usage in specific
environments. To address these promptly, we&#x
GitHub user garydgregory added a comment to the discussion: Roadmap for
`2.25.1` release
>From my POV, I use Jetty, Spring Boot and Spring Batch (š
>https://www.manning.com/books/spring-batch-in-action) for one project, so it's
>good to see 2.25.1 is planned for a July release
GitHub user garydgregory edited a comment on the discussion: Roadmap for
`2.25.1` release
>From my POV, I use Jetty (which has its own OSGi impl), Spring Boot and Spring
>Batch (š https://www.manning.com/books/spring-batch-in-action) for one
>project, so it's good to see 2.2
GitHub user ppkarwasz added a comment to the discussion: Roadmap for `2.25.1`
release
### š ļø Additional Issue: Spring Boot Compatibility
`2.25.0` introduced a regression that affects integration with **Spring Boot**
([[#3770](https://github.com/apache/logging-log4j2/issues/3770)](https
GitHub user ppkarwasz edited a comment on the discussion: Roadmap for `2.25.1`
release
### š ļø Additional Issue: Spring Boot Compatibility
`2.25.0` introduced a regression that affects integration with **Spring Boot**
(#3770):
* For historical reasons, Spring Boot uses `LoggerContext.start
Given the modularity of 3.x, as long as we provide both the jakarta
and javax versions of each, I think we'll be ok. We can revisit
removal of javax variants in the future if they become a burden on
maintenance (e.g., incompatible with newer versions of Java).
On Fri, Apr 1, 2022 at 12:08 PM Ralph
While we need to support jakarta I am not sure it is time to drop javax. Our
history
is to support things until the active user base is very low. Last I heard javax
usage
was still larger than jakarta.
Ralph
> On Apr 1, 2022, at 9:24 AM, Matt Sicker wrote:
>
> On the javax->jakarta idea, I
On the javax->jakarta idea, I think that's a good idea. Every plugin
we have that uses a javax API should have a jakarta equivalent created
and promoted over the old version. We have several of them already;
I'm not sure which ones remain.
On Fri, Apr 1, 2022 at 6:22 AM Gary Gregory wrote:
>
> Ye
Yes, thank you Piotr, it's tremendously helpful :-)
Gary
On Fri, Apr 1, 2022, 03:28 Ralph Goers wrote:
> Thank you for that!
>
> Ralph
>
> > On Mar 31, 2022, at 12:53 PM, Piotr P. Karwasz
> wrote:
> >
> > Hello,
> >
> > On Mon, 28 Mar 2022 at 22:02, Piotr P. Karwasz
> wrote:
> >> The `log4j-1
On Tue, Mar 29, 2022 at 9:11 PM Matt Sicker wrote:
>
> I donāt know if any new javax APIs are defined anymore. Thereās JakartaEE for
> the new APIs, though thatās through Eclipse at this point I think.
>
> Also, for a generic plugin library, there are some things Iād likely do
> slightly differe
Thank you for that!
Ralph
> On Mar 31, 2022, at 12:53 PM, Piotr P. Karwasz
> wrote:
>
> Hello,
>
> On Mon, 28 Mar 2022 at 22:02, Piotr P. Karwasz
> wrote:
>> The `log4j-1.2-api` code seems synchronized between `master` and
>> `release-2.x` up to January 20th. Since part of the desynchroniza
Hello,
On Mon, 28 Mar 2022 at 22:02, Piotr P. Karwasz wrote:
> The `log4j-1.2-api` code seems synchronized between `master` and
> `release-2.x` up to January 20th. Since part of the desynchronization
> that occurred afterwards is my fault and some of my changes are built
> on top of Gary's, I can
gt;>>> likely make a 3.0.0 release before ApacheCon this year (which is Oct
>> 3-6)
>>>> which could make great timing for getting a talk or two accepted at
>>>> ApacheCon (the first and last time I had a talk accepted for this was
>> for
>>>> the 2.0 release). If thatās the case, then I also have a tentative
>> schedule
>>>> we can try to follow:
>>>>
>>>> 1. Make an alpha or beta release of 3.0.0 by June.
>>>> 2. Preferably more than one beta depending on feedback.
>>>> 3. Work on cutting 3.0.0 by September.
>>>>
>>>> Hopefully this timeline isnāt overly optimistic, but I believe weāve
>>>> finally passed some of the toughest parts of the roadmap (Java modules
>> and
>>>> the Great Inversion being two of them). Itād also be great to try to
>> have a
>>>> Log4j release with a Java 11 baseline before Java 11 itself is EOL, but
>>>> thatās not a _requirement_ per se.
>>>> ā
>>>> Matt Sicker
>>>>
>>>>
>>
>>
could make great timing for getting a talk or two accepted at
> >> ApacheCon (the first and last time I had a talk accepted for this was
> for
> >> the 2.0 release). If thatās the case, then I also have a tentative
> schedule
> >> we can try to follow:
> >>
lk accepted for this was for
>> the 2.0 release). If thatās the case, then I also have a tentative schedule
>> we can try to follow:
>>
>> 1. Make an alpha or beta release of 3.0.0 by June.
>> 2. Preferably more than one beta depending on feedback.
>> 3. Work on cutting
se before ApacheCon this year (which is Oct 3-6)
>>> which could make great timing for getting a talk or two accepted at
>>> ApacheCon (the first and last time I had a talk accepted for this was for
>>> the 2.0 release). If thatās the case, then I also have a tentative schedu
Hello,
On Sun, 27 Mar 2022 at 23:59, Matt Sicker wrote:
> * There are dozens (possibly hundreds) of commits that have only been applied
> to release-2.x which need to be copied to master.
The `log4j-1.2-api` code seems synchronized between `master` and
`release-2.x` up to January 20th. Since pa
reat timing for getting a talk or two accepted at
>> ApacheCon (the first and last time I had a talk accepted for this was for
>> the 2.0 release). If thatās the case, then I also have a tentative schedule
>> we can try to follow:
>>
>> 1. Make an alpha or beta release
to follow:
>
> 1. Make an alpha or beta release of 3.0.0 by June.
> 2. Preferably more than one beta depending on feedback.
> 3. Work on cutting 3.0.0 by September.
>
> Hopefully this timeline isnāt overly optimistic, but I believe weāve
> finally passed some of the toughest parts of t
roadmap (Java modules and the Great
Inversion being two of them). Itād also be great to try to have a Log4j release
with a Java 11 baseline before Java 11 itself is EOL, but thatās not a
_requirement_ per se.
ā
Matt Sicker
Iām in an integration phase right now which has raised some
interesting challenges, though I hope to have something functional over the
next few weeks for review.
On Sun, Mar 29, 2020 at 17:16 Ralph Goers
wrote:
> Also, Matt has been working on his dependency injection stuff, but that is
> still
Also, Matt has been working on his dependency injection stuff, but that is
still on a branch. I expect the review of that is going to take some time as
well since I expect he will have modified a ton of stuff.
Ralph
> On Mar 29, 2020, at 3:13 PM, Ralph Goers wrote:
>
> There have been severa
There have been several pull requests submitted since the last release. I am
just going through and verifying them or doing whatever is needed.
In the course of trying to verify the PR for LOG4J2-1360 I have found that
there are a bunch of problems with the javadoc on master that are preventing
Hi All:
I see a current burst of activity on the commit list. I have not looked
closely. Can anyone provide a big picture of what is happening?
Thank you,
Gary
;>>>>>
>>>>>>>> I canāt agree to that. See
>>>>>>>> https://spring.io/blog/2015/04/01/ongoing-support-for-
>>>>>> java-7-and-even-java-6
>>>>>>>> <
>>>>>>>> https://s
;>>>> <
> > >>>>> https://spring.io/blog/2015/04/01/ongoing-support-for-
> > >>> java-7-and-even-java-6>
> > >>>>> for Springās perspective on this. Log4j is such a fundamental
> > framework
> > >>>>&
ective on this. Log4j is such a fundamental
> framework
> >>>>> that, while we need to support new features in the latest JDK, we
> also
> >>> need
> >>>>> to continue to support older Java releases for as long as is
> >>> reasonable.
gt;>>> know a few of you would always like to be on more current JDKs, but I
>>> have
>>>>> worked in environments that are very slow to upgrade. In fact, we just
>>> got
>>>>> a question from someone who is still on 2.2 because they are stuck on
>&
slow to upgrade. In fact, we just
>> got
>>>> a question from someone who is still on 2.2 because they are stuck on
>> Java
>>>> 6.
>>>>
>>>> That said, I am all for discussing what a reasonable timeframe is. I
>> donāt
>>>&g
>>> to continue to support older Java releases for as long as is
> >> reasonable. I
> >>>> know a few of you would always like to be on more current JDKs, but I
> >> have
> >>>> worked in environments that are very slow to upgrade. In fact, we just
reasonable. I
>>>> know a few of you would always like to be on more current JDKs, but I
>> have
>>>> worked in environments that are very slow to upgrade. In fact, we just
>> got
>>>> a question from someone who is still on 2.2 because they are stuc
gt;
> >> That said, I am all for discussing what a reasonable timeframe is. I
> donāt
> >> think 2022 makes any more sense than dropping support in July. Whatever
> we
> >> decide we should give users at least 6 months notice.
> >>
> >> Ralph
> >
d, I am all for discussing what a reasonable timeframe is. I donāt
>> think 2022 makes any more sense than dropping support in July. Whatever we
>> decide we should give users at least 6 months notice.
>>
>> Ralph
>>
>>> On Apr 19, 2017, at 5:18 PM, Matt Sicker
ths notice.
>
> Ralph
>
> > On Apr 19, 2017, at 5:18 PM, Matt Sicker wrote:
> >
> > Roadmap wise, I think dropping support for Java 7 when Java 9 comes out
> > might make sense, though that also depends on where we are release-wise
> at
> > the time. In the me
PM, Matt Sicker wrote:
>
> Roadmap wise, I think dropping support for Java 7 when Java 9 comes out
> might make sense, though that also depends on where we are release-wise at
> the time. In the meantime, modularizing the core more and breaking into
> more subprojects may hel
Roadmap wise, I think dropping support for Java 7 when Java 9 comes out
might make sense, though that also depends on where we are release-wise at
the time. In the meantime, modularizing the core more and breaking into
more subprojects may help find any desires for a semantically breaking
change
On Wed, Apr 19, 2017 at 10:23 AM, Ralph Goers
wrote:
> I have no idea what your versions are, but 2.9 is going to contain the
> first support for Java 9, but it will continue to support Java 7. I am
> assuming your numbering scheme is about what version ONLY supports a
> particular Java release?
I have no idea what your versions are, but 2.9 is going to contain the first
support for Java 9, but it will continue to support Java 7. I am assuming your
numbering scheme is about what version ONLY supports a particular Java release?
I am not in favor of that. With semantic versioning the nu
Hi All,
I like projects that have a road-map page. It can be vague or precise. But
we should at least discuss it here. I am bringing this up partly in light
of https://issues.apache.org/jira/browse/LOG4J2-1883
How about:
v 2.x - Java 7
v 3.x - Java 8
v 4.x - Java 9
Is that too weird? I am not i
40 matches
Mail list logo
