@malexmave, I think the idea of separating Operator and Scanner versioning is quite interesting. If there is a bugfix in the operator that does not influence the scanners, why should I update the scanner charts?

I think it would be nice to have a versioning like this:

Example:
Operator v2.1.1
Nmap: v2.0-7.92-r2

v2 in nmap version indicates that it is compatible with any v2.x.x of the operator.

I think this scheme is fairly similar to option 3. My proposal is not that polished, but a solution like that sounds pretty good to me.

I've updated the ADR to include a Option 5 based on the suggestion of @EndPositive
Any feedback on it welcome :)

Notes to Jop:

• I this your proposal to be more based on option 2 then on option 3(as far as I understood you) :) As your examples didn't include a ARCH version
• I changed the - seperator in the version to a +. - is reseved in semver to indicate pre releases which i think would be more confusing: https://semver.org/#spec-item-9

Hi @J12934 , thanks for adding my option to the ADR. However, I think there is a small misunderstanding. My proposal had the scanners/hooks version number only include the major version of the operator, instead of the complete version.

Again example:
Operator v2.1.1
Nmap: v2.0-7.92-r2

The example from the ADR:
operator: 3.42.0
nmap: 3.42.0+7.92-r2

See how in the ADR option 5, the full operator version is specified. I purposely include only the major version in the nmap version so that small changes in the operator don't require scanner versions to be updated. I think that is also why it is more similar to option 3 than to 2.

I like your proposal in general. I am not quite sure how it would handle a case where we make an improvement to a scanner without updating the version of the scanner itself though. Like saying "oh, actually, there is another piece of interesting data in the output of the scanner, let's quickly change the parser to also expose this in the findings". Since the embedded scanner remains on the same version, and the operator also remains the same, how would a version update like this be numbered, especially in an automated fashion? Similarly, what if we update the parser base image and need to re-generate all parser images - how would this reflected in the versioning scheme you propose, @EndPositive? The solution by @J12934 has the advantage that we have the entire version number to play with, which makes changes like this easy.

Or, put another way: Why is it bad that the scanner version needs to be updated for small changes to the operator (because this seems to be the basic premise of your proposal)? At the moment, we are releasing numbered versions for all parts of the system on every release, regardless of if they changed or not. This way, you can always just pull all version numbers up on upgrade, and if you see that parts of your stack are running on 3.3.1 and parts on 3.4, you don't need to wonder if this is because 3.4 did not make any changes to them or because you forgot to pull this component up to v3.4.

Since the embedded scanner remains on the same version, and the operator also remains the same, how would a version update like this be numbered, especially in an automated fashion?

That's what I reserved the minor version for. E.g.:

nmap: v2.0-7.92-r2 -> v2.1-7.92-r2

Updating the SDK would result in all scanners/hooks releasing with a minorversion update. That might be a bit confusing when multiple scanners are on the same SDK, but not on the same minor (e.g. because one has updated params).

Why is it bad that the scanner version needs to be updated for small changes to the operator (because this seems to be the basic premise of your proposal)?

Like you mentioned earlier, it is very likely that third-party developers maintain their own scanners. I can't imagine they release a new scanner version for each release that is made here. Simply because there may not be a requirement to do so. How many times do we make a release for scanners that have 0 changes?

By modularization like this I hope you can also find that there is less maintenance in releasing new scb versions.

It is a common concept to modularize like this. ZAP addons also update independently from ZAP. Nuclei templates are also modular from nuclei engine. Differnece between these and my proposal was that the core version is not mentioned in module version, only in changelog.

By modularization like this I hope you can also find that there is less maintenance in releasing new scb versions.

We had modularization in SCBv1 and it was a hell. That's why we decided to maintain everything like a monolithic software w/ single version. Turns out it is not sufficient :-(

Complete other idea: Is it feasible to somehow implement a dry-run upgrade, so that I can check if something will break? If this is possible we may not need any versioning.

When releasing breaking changes, it would probably be nice for users to be noticed upon installation/upgrading. This could happen not only by putting the breaking release note prominently at the top of the release notes, but also to have them in the Helm notes of the respective scanners (The process of doing that should be automated, of course..)

I have updated the ADR with our decision in the meeting we had today.

This decision is made with the knowledge that it may have consequences we are unaware of. We thus invite people who disagree with it to let us know by creating a discussion or opening an issue.

It results in the following new TODOs:

• Update release-drafter template to implement ADR-0011 #1023
• Explain the versioning scheme in the documentation, likely as part of the forthcoming "upgrading" page
• Check "upgrading" and "versioning" information in repository #1024