Yes there are still people using COBOL, changing that is not a case of upgrading a library though, so it’s really a straw man argument.
There is nothing stopping people from forking log4j and using their own fork, if that’s a better option for them than upgrading to a 2.x version of log4j, they should do that. The problem with making an official release that fixes 1.x.x is that you are officially supporting it and you will be expected to support other changes. I can see why the log4j team would not want to do that, it’s a waste of time and effort and they only have so much time to spend on (probably not paid) open source work. As you have noted fixes for 3.x and 4.x versions of JMeter would be hard because you use gradle to build now instead of Ant. I would suggest that the time required to fix these old versions, get the build environment up and running again and the release config set up is probably just not worth the effort. Just ask people to move to the latest version. If you want to support obsolete versions, and have the time to do it, that’s totally up to you (and fair play to you). However I would suggest that it would be more valuable to use that time and effort on making the current version better and encouraging/helping people to stop using the obsolete stuff. It’s a fact that nothing can be supported forever. There comes a point where you have to bite the bullet and upgrade, or build something newer which is a better fit for current problems. > On 21 Dec 2021, at 11:35, Vladimir Sitnikov <sitnikov.vladi...@gmail.com> > wrote: > >> People have had nearly a decade > > ... to remove COBOL from their apps. > Seamless migration does not exist yet, and people have large apps that > can't really be upgraded that easily. > They would rather fork log4j and use their own fork. > >> This is more akin to asking the JMeter team to support JMeter 2 > > Suppose: > 1. someone asks to fix CVE in JMeter 1 > 2. they are eager to implement the fix > 3. they provide a reasonable explanation why they can't upgrade > > I would expect: > a) JMeter team to implement the fix > b) or co-operate with getting the fix released (e.g. create Git branch, > accept PRs, etc, prepare versions). > c) or give away control over JMeter 1 so other contributors can implement > 1.x fixes and release 1.x versions. > > For instance, option "c" might be selected by JMeter team if applying fixes > and releasing takes too much effort. > For example, if somebody adds GitHub Actions CI to JMeter 1.x I would be OK > to review and merge it. > > Does that answer your question? > >> I would fully expect you to say move to the latest version where we have > fixed this issue > > Note that we are about to release JMeter 5.5 with new features. > The repository is all good for the release, however, the team did > back-patch 5.4.2 > Back-patching 5.4.2 was not my idea, and I appreciate the ones who did that > (Milamber?) > >> I wouldn’t expect you to patch JMeter 2, 3, 4, and 5. > > JMeter 2 is not using log4j2, so it is not that impacted. > We assume 5.x->5.4 upgrade is workable for everybody, and nobody voiced > they are stuck with 5.0. > I know people might be stuck with 4.x, and 3.x (that are affected by log4j2 > CVE), so it would be responsible > to release those versions as well. > > Unfortunately, 3.x and 4.x are Ant-based, so the release steps are way > harder there than we have now. > > Vladimir
