OASF Release Process

[akijakya]

Hi team,

I'd like to clarify and document our release process for the OASF project to ensure everyone is aligned.

Release Branches and Versioning

• We use release branches for each schema release because the schema and server are shipped bundled within a Docker image.
• The schema itself should never be changed once published, but the server can be improved independently.
• It is common to cherry-pick commits and update the server for earlier schema versions to fix bugs or add features that should be present across all OASF versions.
• We bump the minor version when the schema changes, and the patch version when only the server changes.

Release Steps for a New Schema Version

1. Create a release branch named after the version number without the v prefix (e.g., 0.6.0) to avoid collision with tag names.
2. Push a commit to that branch updating the version number in schema/version.json to the new version. Also bump the server version to the same version number in server/mix.exs.
3. Tag the commit with the new version tag (e.g., v0.6.0) and push it so the CI pipeline can create the packages.
4. Generate release notes on GitHub and publish the new release.
5. Do not delete the release branch after the release.

Tasks After a Schema Release

• Open a pull request to the main branch where the version in schema/version.json is bumped to the upcoming schema version with the -dev suffix, for example, 0.7.0-dev.
• Adjust the versions in install/charts/oasf/values-test.yaml and install/charts/oasf/values-test-versions.yaml so that local development versions are displayed correctly during project development.

Backporting Server Changes to Earlier Versions

• Checkout the relevant release branch.
• Create a new branch from it and add or cherry-pick the necessary server changes.
• Bump the server patch version in server/mix.exs.
• Open a pull request for review.
• Once merged, tag and push a new patch version (e.g., for branch 0.6.0, tags would be 0.6.1, 0.6.2, etc.).

API Version Bumping

• The API version in server/lib/schema_web/router.ex only needs to be bumped when the API endpoints themselves are changed.

Releasing a New Chart Version

• Use tags with the prefix helm/ followed by the version number, e.g., helm/vX.X.X.

Please follow this process to maintain consistency and ensure smooth releases across all OASF versions.