Hi Gilles, On Wed, 16 Oct 2024 at 09:52, Gilles Sadowski <gillese...@gmail.com> wrote: > > Offering LTS branches with extended security support is not a choice a > > single project can make: a good LTS version must only use LTS versions > > of its dependencies. Since we depend on Commons, such an initiative > > should be ASF-wide. > > And "Commons" doesn't/can't make any LTS promise. > Rather, it has always stated that only the latest release is supported. > [The first question to someone reporting a bug in an older version is > whether it exists in the latest release.]
Neither does Log4j officially. The 2.3.x (last release compatible with Java 6) and 2.12.x (last release compatible with Java 7) did receive security updates, but I don't think they were ever designated LTS. I am not proposing to backport *all* bug fixes to an older branch, but just the critical ones (OpenJDK-style): * CVEs fixes should be backported, * update to direct dependencies that fix a CVE in the dependency, might be backported. So normal bugs that affect only the old release, would not be addressed: users would still have to prove that those bugs affect the latest version. Only those affecting security would be fixed. This way users seeking stability could only upgrade a Commons dependency every couple of years. Dependency Track could be taught not to warn them about an "outdated dependency version" as long as they stick to the LTS (and the LTS is supported). Of course this also has a negative impacts on the CVE-release process: * whenever an LTS branch is updated, you can expect a CVE being announced shortly after. Piotr --------------------------------------------------------------------- To unsubscribe, e-mail: security-discuss-unsubscr...@community.apache.org For additional commands, e-mail: security-discuss-h...@community.apache.org
