Hello I have been the person cutting the 1.2.17 release and what I remember was it was a super hard build. I had to install some VMs because there were weird dependencies to this build. Building it fully will not be easy, but I can also look into some mails whatever I found from that time. Here is some build info.: https://github.com/apache/logging-log4j1/blob/trunk/INSTALL Some unit tests only run with a Windows VM
It would be easier to remove some components, but BC is broken then. We told people in August 2015 this is EOL. I am honestly surprised that we discuss a new release after 7 years. To my understanding the JMSAppender issue is not as critical (just don't configure it). If a reconfiguration of system is not on the cards, I wonder if upgrading from 1.2.17 to 1.2.18 is. That said i don't think we should resurrect it. If somebody really wants to work on, I also don't think we should go through the incubator. We can do this using the normal processes and apply patches, vote on new committers etc. My 2 cents. Christian On Mon, Dec 20, 2021, at 01:36, Gary Gregory wrote: > Improving legacy compatibility is what I've been pushing. I agree with > Matt. IMO resurrecting 1.x sets a bad precedent and is a proverbial can of > worms. > > Gary > > On Sun, Dec 19, 2021, 17:55 Matt Sicker <boa...@gmail.com> wrote: > >> The alternative is to polish the 1.x compatibility in 2.x which is both >> actively maintained and much easier to get releases published. Then users >> on 1.x can more easily upgrade to 2.x. I can almost guarantee that >> regardless of how many warnings we add to a potential 1.x release, we’ll >> get inundated with CVE reports, bug reports, and email, all related solely >> to 1.x which none of us wish to maintain (especially given most of us >> weren’t even involved in 1.x back when it was in development). >> -- >> Matt Sicker >> >> > On Dec 19, 2021, at 16:48, Vladimir Sitnikov < >> sitnikov.vladi...@gmail.com> wrote: >> > >> > Matt>but at least one release using the normal ASF release requirements >> is >> > required to graduate. >> > >> > Thanks for the reminder, and I am sure preparing the release won't be an >> > issue. I refactored release scripts for both Calcite and JMeter, and I am >> > sure log4j 1.x is doable. >> > >> >> compared to the alternatives discussed in this thread. >> > >> > I must be missing the alternarives. >> > Can you please highlight them? >> > >> > There were multiple suggestions and various PRs from external >> contributora, >> > yet the committers respond with vaugue messages. >> > >> > The code must be buildable, so moving to Git, and adding GitHub CI is the >> > mandatory step. >> > Of course, the existing PMC members and committers might have opinions on >> > the way to fix the issues, however I see no reasons for the team to deny >> > Git. >> > >> > The migration to Git consumes absolutely no resources from committers, >> > except a couple of +1 votes. >> > >> > Unfortunately, even a trivial improvement like Git is ignored by Logging >> > PMC. >> > >> > So I take Ralph's suggestion to reestablish the new PMC for log4j 1.x >> > seriously. >> > >> > Vladimir >> >>
