## Problem API Security is using a versioning and release process that was inherited from the acquisition of the technology. The process is different than other analyzers, and doesn't match GitLab's semantic versioning. API Security is also not capturing a changelog for each release. This makes it much harder for customers to understand what each release does and when they should upgrade. Timeline: Complete prior to %16.0. ## Proposal ### Versioning Versions will be "MAJOR.MINOR.PATCH" - MAJOR: Incremented when changes are not backwards compatible. - This number will be incremented yearly in conjunction with GitLab's major number incrementing. - Our major version number will not match GitLab's. - MINOR: Feature changes. - Increments for each published container image. - PATCH: Patch for an existing MAJOR.MINOR release. - Unlikely to be used often. #### What is our current versioning method? Our current versioning system is `MAJOR`.`MINOR`.`BUILD`. Both `MAJOR` and `MINOR` are manually changed by setting values in `peach-web.properties`. Each default-branch pipeline increments `BUILD` and gets a `vMAJOR.MINOR.BUILD` tag. When we publish one of our builds a new tag `pub-vMAJOR.MINOR.BUILD` is added. This creates gaps between versions (not every version is released). ## Changelogs Each public release should include a changelog. Use GitLab's built in ability to manage a changelog. - [Update changelog](https://docs.gitlab.com/ee/api/repositories.html#add-changelog-data-to-a-changelog-file) ## Release pipelines Version numbers are injected into our code at build time. To keep our existing build process the release process will change to require a pipeline flag. ### Releasing When publishing a new container, a new "release" should be created with the changelog. The releases should be here: - https://gitlab.com/gitlab-org/security-products/analyzers/api-fuzzing-src - https://gitlab.com/security-products/api-security/-/releases You can see how its done here: - https://gitlab.com/gitlab-org/security-products/dast/-/releases Links: - [Release keyword ref](https://docs.gitlab.com/ee/ci/yaml/#release) Associate milestone with release: - Requires API call or manual UX Evidence: - Artifacts are added to release evidence - Reports are not added by default unless specifically collected as artifacts Support release freeze by adding this rule: ```yaml rules: - if: $CI_DEPLOY_FREEZE == null ```