On Thu, Nov 2, 2023, at 17:04, Gary Gregory wrote:
> Log4j 3 matching Spring 3 seems obviously a good thing to me. Going to Java
> 17 seems to me as well a good thing.
>
> Gary
>
> On Thu, Nov 2, 2023, 7:04 AM Ralph Goers <ralph.go...@dslextreme.com> wrote:
>
>> I should add that I am concerned that we are missing a huge opportunity
>> with Spring 3. A lot of folks will start their migration to Spring 3 early
>> next year. Tying Log4J 3.x to that is a big opportunity for people to
>> upgrade at the same time.
If this is the case, then how would we achieve the goal of releasing it
together?
With flume, audit and the other stuff eating time, it will be hard to get this
done.
This workload is too much for this handful of people. Removing load was btw
also the idea of retiring components, so we can spend this time on other things
of interest
I would like to suggest that we have a team call soon where we collect our
ideas of how we can reach that and refresh our shared vision.
Btw what is meant with spring 3? Spring boot is 3.1.15 already, spring
framework is 6.x.
>>
>> Ralph
>>
>> > On Nov 2, 2023, at 3:53 AM, Ralph Goers <ralph.go...@dslextreme.com>
>> wrote:
>> >
>> > Piotr, I haven’t committed much to 3.x since June because it already
>> has everything I set out to do. It is everyone else who keeps adding crap
>> that “must” be done before it can be released. Yet another year is far too
>> long. If that is the case my vote is to skip the additional stuff. And I
>> will always be fine other oving things if they are no longer supportable or
>> need to be separated into a new module so long as end user code doesn’t
>> have to be changed.
>> >
>> > Releases do not have to be perfect. In fact, someone advised me once
>> that you don’t want them to be as that is how you draw in new committers.
>> >
>> > Ralph
>> >
>> >> On Nov 2, 2023, at 2:10 AM, Piotr P. Karwasz <piotr.karw...@gmail.com>
>> wrote:
>> >>
>> >> Hi Ralph,
>> >>
>> >>>> On Thu, 2 Nov 2023 at 09:42, Apache <ralph.go...@dslextreme.com>
>> wrote:
>> >>> I’m confused. 3.0.0 hasn’t even been released so how can I be
>> preventing adding anything. Personally I would prefer the monitoring to be
>> in a separate repo but I am ok with adding it to the main build. IAM all
>> for moving async out but unless it can be done quickly I’d rather do it in
>> a future 3.x release. The same is generally true for your other bullets as
>> well.
>> >>
>> >> What I meant: we can not **remove** anything after 3.0.0 GA is
>> >> released, this includes module refactorings.
>> >> I know that you are pushing hard to have a beta by the end of this
>> >> year and GA shortly after.
>> >>
>> >> The problem is: the development of 3.x has been stagnating since June.
>> >> Since then I have only seen Matt, Volkan and myself committing
>> >> something.
>> >> Since most of these changes can not be done in our day jobs, a more
>> >> realistic release date for 3.x is the end of the year 2024.
>> >> Right now the JLink project I added to Samples works with 2.x, but
>> >> **fails** with 3.x (besides, 3.x snapshots are not getting published
>> >> since a month and I don't have the faintest idea why).
>> >>
>> >> Piotr
>>
>>
