Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarification on supported versions #5159

Open
mamccorm opened this issue Aug 1, 2024 · 6 comments
Open

Clarification on supported versions #5159

mamccorm opened this issue Aug 1, 2024 · 6 comments

Comments

@mamccorm
Copy link

mamccorm commented Aug 1, 2024

Hi there,

I'd like to ask for some clarify on which versions of couchdb are actively maintained, and when we might see subsequent patch releases. If some documentation exists, i'd be grateful if you could link here.

Otherwise, i've been trying to determine by looking at Git releases, and this is what I can see:

  • v3.3.3 - Latest release, last cut in December 2023
  • v3.2.2 - Last cut in April 2023
  • v3.2.3 - Last cut in April 2023

Going from the above, it doesn't look like the project is being actively maintained, at least in the sense of publishing releases, it's been 8 months since the last release was cut, and 14 months since the previous, and no patch releases since.

If I look at the images on Dockerhub, it does look like some of the tags are being re-pushed, i.e these ones look to have been pushed in the last couple of weeks:

Older tags don't look to have been pushed any time recently. So it looks like we're re-building v3.2 and v3.3, does that mean these are the two supported versions? and if supported, how come we aren't cutting patch releases to maintain them in GitHub?

Another reason that makes me think v3.2 is not being maintained - a GH issue was opened to fix a CVE, but it looks like this was closed, and fixed in v3.3 instead (i.e not addressed in v3.2).

When I look at both images, they also have a lot of vulnerabilities, which is the part of the reason for exploring the above, example:

% grype couchdb:3.3.3
...
...
 ✔ Vulnerability DB                [no update available]
 ✔ Pulled image
 ✔ Loaded image                                                                                                                              couchdb:3.3.3
 ✔ Parsed image                                                                    sha256:1d8323a5b9e3888f3adc3e8468857bb983688bec36be7cc196b7b8ea2b846d8e
 ✔ Cataloged contents                                                                     13044b00fd70799b183580943c83b1179a69f4f9da246144898f4032cd0a0b24
   ├── ✔ Packages                        [137 packages]
   ├── ✔ File digests                    [5,170 files]
   ├── ✔ File metadata                   [5,170 locations]
   └── ✔ Executables                     [811 executables]
 ✔ Scanned for vulnerabilities     [170 vulnerability matches]
   ├── by severity: 6 critical, 17 high, 33 medium, 9 low, 86 negligible (19 unknown)

Also, i'm aware a lot of these may come from the choice of base image - upgrading from bullseye to bookworm would remediate a large chunk of them, but there'd still probably be over half remaining. Might be something worth considering?

Anyway, confirmation on what versions are supported, would be great, and thanks in advance

@rnewson
Copy link
Member

rnewson commented Aug 2, 2024

The rule is we support the current and the last feature release line. So when 3.4 comes out, 3.2 becomes EOL, and so on.

This rule is for CouchDB itself. The CVE's in the docker images are for unrelated (and unused) packages afaict, and should be addressed by an image rebuild (this is supposed to be automated...)

@rnewson
Copy link
Member

rnewson commented Aug 2, 2024

As for release cadence, CouchDB is a mature project with a small dev team. There are not many releases in a year, patch level or feature level, but the project is definitely active. a 3.4 release is coming out soon.

@mamccorm
Copy link
Author

mamccorm commented Aug 2, 2024

Thanks @rnewson, that was helpful and appreciated. Would you be open to accepting a small contribution to update the README?

@rnewson
Copy link
Member

rnewson commented Aug 2, 2024

I'm surprised it's not written somewhere. Since its project policy we're defining I'm going to propose my own PR with similar but hopefully clearer text.

@rnewson
Copy link
Member

rnewson commented Aug 2, 2024

#5162

@rnewson
Copy link
Member

rnewson commented Aug 2, 2024

@mamccorm we've merged #5162 in response to this issue. I hope that's helpful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants