Re: [clamav-users] Long Term Support (LTS) program proposal

[Scott Kitterman via clamav-users]

On July 28, 2021 11:53:35 PM UTC, "Micah Snyder (micasnyd) via clamav-users" 
<clamav-users@lists.clamav.net> wrote:
>
>Hi All,
>
>For the past couple of months I've been promoting the idea of having Long Term 
>Support (LTS) feature releases for ClamAV within internal Talos communications.
>
>For the purposes of this discussion:
>
>  *   A "feature release" is a version starting with MAJOR.MINOR.0 to include 
> all PATCH versions. I.e. ClamAV 0.103.0, 0.103.1, 0.103.2, and 0.103.3 are 
> all within the same "feature release".
>  *   A "patch version" is a specific MAJOR.MINOR.PATCH version. E.g. 0.103.4 
> would be the next "patch version" in the 0.103 "feature release".
>
>My interest in starting an LTS program came about because we have been getting 
>(understandable) pressure from management to have shorter development times 
>for feature versions with more targeted feature sets.  What this means is that 
>you would see more frequent feature releases, possibly as many as ~5 per year. 
> Some of the features in a given feature release would be things the community 
>cares about, while others may be by request of a different team within Talos 
>or Cisco.
>
>But I couldn't in good conscience start pumping out new feature releases every 
>2-4 months and expect everyone to keep up. And at that rate it would not be 
>possible for us to make critical patch versions for every feature release 
>within the two years, or even one year.  So in order to get features out 
>faster it became clear to me that we will need to define specific feature 
>release for which we promise to backport security fixes for some amount of 
>time.
>
>This raised a few obvious questions:
>
>  *   Which feature release do we start with?
>  *   Do we have to continue serving signature database content to every patch 
> version in an LTS release?
>  *   How often should we select a new feature release for LTS?
>  *   How long is "long term support" anyways?
>
>We've been talking about this off and on for the past couple of month.  This 
>is what I came up with....
>
>Which feature version do we start with?
>
>We had initially settled on 0.104 as the first LTS version, for basically two 
>reasons:
>
>-          Joel really wants to make sure people have the latest freshclam 
>features, particularly those found in 0.103.2 and 0.103.3, to reduce bandwidth 
>cost.
>
>-          I don't want to keep fixing glitchy autotools package detection 
>issues for years to come.
>
>But after seeing the (very much unexpected) reaction to the switch CMake... 
>it's clear to me now that we need to start the LTS program with 0.103.
>
>Do we have to continue serving database content to every patch version in an 
>LTS release?
>
>No.
>
>LTS means that we will promise to continue providing patch versions for a 
>given feature release.
>I.e. you will get critical fixes in 0.103.4, 0.103.5, 0.103.6, etc. as needed 
>until End of Life (EOL) for the 0.103 feature release.
>
>I need to stress that it doesn't mean people should or will be allowed to 
>continue using vulnerable or otherwise problematic versions such as 0.103.0 
>and 0.103.1 just because they belong to an LTS feature release. We will 
>reserve the right to at some point begin to block older patch versions like 
>0.103.0 from downloading databases to force people to use newer patch versions.
>
>How often should we select a new feature release for LTS?
>
>Some products, like Ubuntu, do a new LTS ever 2 years with support for 5 
>years.  2 years feels like a long time but, as much as I want to get people 
>using the latest features, our team is pretty small.  The more frequently we a 
>release for long term support, the more work each security release will be.  
>We would be required to create and test a new patch version for the current 
>stable feature release plus a collection of LTS releases. If we did an LTS 
>every year, that would be too much.
>
>I think 2 years is probably a good number.
>
>How long is "long term support" anyways?
>
>As noted above and elsewhere, Ubuntu and RHEL/CentOS support LTS versions for 
>5 years.  That's a long time, and more than our team could agree to.
>After a bunch of discussion, we think 3 years is a good number.
>
>To summarize, I'm proposing a Long Term Support (LTS) program for ClamAV 
>starting with the 0.103 feature release.  This means:
>
>
>  1.  We will promise to provide critical patch versions (0.103.4, .5., .6, 
> etc.) as needed until the LTS end-of-life.
>This does not mean that the original 0.103.0 or other problematic patch 
>versions within the series will continue to "work".
>Users MUST be willing to upgrade to newer patch versions within a given LTS 
>release.
>
>  2.  Each LTS release would be supported for three (3) years from the first 
> (.0) version.
>
>0.103.0 was published in August 2020.  This means we would continue to provide 
>critical patch versions for 0.103 until August 2023.
>
>  3.  We will aim to select a new LTS feature release every two (2) years.
>
>With 0.103 starting the LTS program, that means that whichever feature release 
>is to be published near abouts August 2022 is the likely candidate for the 
>next LTS release.
>
>
>
>  1.  When a security fix is required, we'll publish a patch version for the 
> latest feature release as well as all affected active LTS feature releases.
>
>  2.  We will document the LTS policy and add an end-of-life version table to 
> https://docs.clamav.net/faq/faq-eol.html.
>
>
>I would like your feedback.

I can see advantages to Debian if we can stay on an LTS release.

I would suggest adding maintaining stable ABI in libclamav  throughout the LTS 
should also be a requirement.  We've had to do soname bumps in our stable 
release before and it's pretty painful.  It'd be nice not to have to worry 
about that anymore.

If you would make the LTS support lifetime 4 years instead of three that would 
give you a consistent 2 LTS releases to support and would allow us to get on an 
LTS release during development and stick to it for the normal support period of 
a Debian release.  Please consider.

Scott K

P. S.  I haven't been active on Debian clamav maintenance for awhile, so if 
Sebastian has a different view, definitely go with that.

_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml