Hello Piotr. Le mer. 16 oct. 2024 à 10:49, Piotr P. Karwasz <piotr.karw...@gmail.com> a écrit : > > 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. >
Given that no "branch" is currently tagged "LTS", nothing (not even a CVE fix) has to be backported. What are the criteria for deciding that some branch must be "LTS"? Who is going to take the responsibility to impose to someone else (probably) that, some "x" years from now, some (expectedly outdated) code base _must_ be released, with some CVE fixed, but otherwise containing known bugs that were fixed in the intervening releases? "Commons" has been following a policy to make it easy and (hopefully) harmless to upgrade to "minor" releases. A "major" release does not occur often; and for functionality that exists in the previous release, upgrading user code is mostly done via trivial "search and replace". Developers who don't want to integrate this minimal effort are not entitled to expect us to take on the huge burden of LTS. Regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: security-discuss-unsubscr...@community.apache.org For additional commands, e-mail: security-discuss-h...@community.apache.org
