It sees the entire _secureCodeBox_ as **one large piece of software with many components** that are all equally important to the overall compatibility, and where all components are (usually) updated in lockstep.

As illustration, here are a few examples and what kind of release they would require:

1. **MAJOR versions indicate that manual action may be required to keep existing workflows running** and that the users should read the changelog. However, it may turn out that the breaking change does not apply to the users' environment (e.g., because they are not using a specific scanner), in which case no manual action may be required.

The MAJOR version number indicates compatibility between the operator and scanners, while MINOR version changes can still be breaking to some users (in which case this will be denoted prominently at the top of the release notes).

As illustration, here are a few examples and what kind of release they would require:

1. **MAJOR versions indicate that a joint upgrade of operator and scanners is required,** which is highly relevant in environments where operator and scanners are maintained by different teams (we know that these environments exist, and want to support them). This obviates the need for a detailed compatibility matrix between scanner and operator versions.

A different variant of the previous option would be to prefix the version number with an ARCHITECTURE (ARCH) number, so the final versioning would be ARCH.MAJOR.MINOR.PATCH. In that case, the table would look like this:

| Action |Version |

This could be considered "playing tricks" (by just adding a digit and relabeling the meaning of the positions) and would deviate from semver, but would allow us to use the ARCH number to denote operator compatibility, while the MAJOR version denotes scanner compatibility, the MINOR indicates feature additions, and the PATCH indicates bugfixes.

**Example Version Numbers:**

- e.g. embedded version / version range of supported DefectDojo version in build meta

- might not be necessary / possible for every hook. And thus make the hook versioning schema inconsistent

This makes the proposal still not completely Semver compliant as the command line flags of the scanner can still break in minor releases, but these can be easily detected as the user will notice that the version number of the scanner has jumped a major release.