Again, you cannot break binary compatibility in a minor release. That's a show stopper.
This discussion IMO should ONLY be about mitigation of CVEs and that means porting the idea of the fixes from 2.x to 1.x. This 1.x component is EOL. I say "idea" because the code bases for 1.x and 2.x are completely different. >From my point of view, any other edits are DOA. I am focusing my 1.x efforts in improving compatibility in 2.x for 1.2 behavior in the log4j-1.2-api module. Towards this goal please see the 1.2 bridge fixes in 2.17.0. If you want to help 1.x users in the best manner possible, IMO, help them move forward to 2.x by helping on the mailing lists, Jira, GitHub, Slack, there is no shortage of work to be done. Ty, Gary On Sat, Dec 18, 2021, 13:17 Leo Simons <m...@leosimons.com> wrote: > On Sat, Dec 18, 2021 at 5:32 PM Leo Simons <m...@leosimons.com> wrote: > > > On Sat, Dec 18, 2021 at 3:34 PM Gary Gregory <garydgreg...@gmail.com> > > wrote: > > > >> If you delete anything that is public or protected, you will break > >> binary compatibility, and that's a no-go IMO. > > > > > > Agree. I hope we can get clirr (or something like it) back to work, to > > prove binary compatibility. > > > > Sorry for the extra mail but I'm excited, I just learned japicmp exists :-) > > "Someone" wrote a nice blog post on how to use it... > > > > https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/ > > So the setup was easy to steal... > > https://github.com/apache/commons-lang/blob/master/pom.xml > https://github.com/apache/commons-parent/blob/master/pom.xml > > Leads to question: how do we feel about removal of .lf5 (javax.swing > logging) and .chainsaw (java.awt logging) packages? > > It's an old change that was already on the trunk. > > > > https://github.com/apache/log4j/pull/16/commits/5c29c4048b4860aa7f6a86420f20208459e6c22c#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R251 > > I can understand why it was made. > > > Cheers, > > > Leo >
