Talking about LTS.. Something I perceive as a great feat is a well defined lifecycle definition, even without any special labels like LTS. See ubuntu for reference:
https://ubuntu.com/about/release-cycle With a well defined lifecycle definition consumers can think about and plan the future in the moment when they become a consumer of a product. On Wed, 16 Oct 2024, 20:34 Piotr P. Karwasz, <piotr.karw...@gmail.com> wrote: > Hi Gilles, > > On Wed, 16 Oct 2024 at 13:47, Gilles Sadowski <gillese...@gmail.com> > wrote: > > 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? > > I don't mean to impose to any project to create "SECURITY ONLY" > branches, but such branches do not seem to bring a lot of additional > work (there are not a lot of vulnerabilities). Since _de facto_ some > users will keep the same version of a dependency for years, why not > make the ecosystem more secure and let them use a "SECURITY ONLY" > branch with "SECURITY ONLY" dependencies? > > After a couple of years a "SECURITY ONLY" branch can reach "END OF > LIFE" or reach what Jetty calls "End of Community Support"[1]: > security fixes will be guaranteed for everybody as long as some > commercial entities pay a large enough group of maintainers to > backport security patches[3]. This is also the model adopted by the > Extended LTS model in Debian. > > [1] https://github.com/jetty/jetty.project/issues/7958 > [2] https://wiki.debian.org/LTS/Extended > [3] I believe such a model is compatible with the Apache governance, > since _vetos_ on a backported patch should also apply to the original. > > > "Commons" has been following a policy to make it easy and (hopefully) > > harmless to upgrade to "minor" releases. > > Log4j has the same policy, although it doesn't always work out for > everybody. There is also a psychological barrier for "minor" releases. > Some users explained to me that they prefer Logback over Log4j Core, > since the former keeps supporting older branches (like 1.2.x), while > Log4j drops support for a minor branch once the next is published. > Logback is not semantically versioned, so the 1.2.x branch contains > new features and can even contain breaking changes, but it looks like > a "safer" choice. > > Piotr > > --------------------------------------------------------------------- > To unsubscribe, e-mail: security-discuss-unsubscr...@community.apache.org > For additional commands, e-mail: > security-discuss-h...@community.apache.org > >
