To be extremely specific, the LTS version would start with 0.103.3. So that would be the base version we’d support for LTS.
> On Jul 29, 2021, at 10:06 AM, Andrew C Aitchison via clamav-users > <[email protected]> wrote: > > > Executive Summary: > An LTS release every two years, supported for three, starting with 0.103 > sound good to me. Thank you. > > > On Wed, 28 Jul 2021, Micah Snyder (micasnyd) via clamav-users wrote: > >> 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. > > I don't *think* I want ever more features (though I may say "yes" when > you suggest X and Y ... and Z ...). What I want is better detection > (though I don't currently have an SMTP listener, so the number of > pieces of malware my installation could detect is vanishingly small). > > I can see management wanting you to work on one new feature at a time, > releasing it and moving on to the next. If that works for your team, fine. > If you work better by being able to switch between a couple of projects > and release several at once, that is fine too. > However, please make a release when it is ready; don't go down the > Firefox route of a release timetable with features trying to catch the > release train where they can (not that I think your team is big > enough to do that). > > >> 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. > > Thanks. > Sorry if that means you have to put up with a build system > you don't like for another two years. > >> 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. > > It will be interesting to see which distros use the LTS and which > keep up with the feature releases. > > >> 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. > > Tuesday, August 18, 2020 ClamAV 0.103.0 release candidate > Monday, September 14, 2020 ClamAV 0.103.0 released > > So we are going by the (first) release candidate. OK. > >> 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. > > Thanks, > > -- > Andrew C. Aitchison Kendal, UK > [email protected] > > _______________________________________________ > > clamav-users mailing list > [email protected] > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ clamav-users mailing list [email protected] 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
