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
and...@aitchison.me.uk
_______________________________________________
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
