Consider creating major/minor/patch tagged releases in GHCR for your official releases

[mig5]

Which version are you referring to?

3.2.x

Did you read the FAQ?
Yep

---

Hi @drwetter - I noticed that in your Github container registry, there's been a new push of '3.2' tag, but the last 'official' release dates from February (3.2.3).

I am trying to set up a workflow that notifies me when you make a new release and that allows me to fetch the new GHCR Docker image. Do you think it would be possible for you to:

a) push semantic version tags for the actual releases to GHCR, e.g 3.2.4
b) only push to 3.2 when you make an actual official release (e.g 3.2 would then be an alias to the latest release tag e.g 3.2.4)
c) consider your automation workflow to push to a 'nightly' tag or 'dev' tag or something rather than to the actual semantic major/minor version tag?

I appreciate that this would involve a bit of a change to your current workflow, and you may not wish to do it, but it's just what I see other software developers doing. Everyone's different of course. Just an idea, feel free to close if you don't want to do it. :)

Thanks for all your work on testssl.sh over the years!

[drwetter]

Thanks for your "thanks", much appreciated!

First of all: Everything is possible , almost ;-) . For 3.2.x however not sure whether c) and b) make sense. 3.2.x is a stable branch. It won't get breaking changes or new features. It receives maintenance updates and bug fixes, the number is not huge over time. If they pile up, there will be a new release. I'd rather like to have users to get the latest maintenance updates and bug fixes before that. "Nightly" in a stable branch or even "dev" in counterproductive.