# Release Process

## Issues right now

* Release waiting for "things to be done"
* Releases need to get coordinated (effort)
* Very short time window where released versions actually run together
* Not a lot of testing of releases
* Current process favours coupling between components

## How to improve it

Teams should be able to make component releases any time.
Releases of `renku` should be able to be made at any time just off of what is currently on master.
To that end, teams should already prepare the changelog in the auto-prs in the `renku` repo, so whoever makes the release doesn't need to hunt which teams need to include something and for them to write release notes.

The process would then look like:
- Individual teams make component releases whenever they want/need
- A component release create an auto-pr on `renku` (same as now)
- The auto-pr only gets merged to master once the release notes/changelog are are filled in (in a `latest` section that can then be renamed to the actual version on release). Do NOT just copy your component changelog, but rewrite it for the larger audience so it's self-explanatory.
- The auto-pr is merged to `renku` master and gets deployed to Dev
- For a `renku` release, a release PR off of `renku` master can be made any time, bumping the version and doing an editorial pass over the changelog. This is done every monday after the renku meeting at 12. Any change that didn't make it to master at this time is NOT included.
- Once that PR is merged, it gets tagged, release and the CI machinery for deploying it kicks off
- *Wait to deploy to `Renkulab` until a release was on `limited` for a week?*

If a component made a release that turns out to be faulty (but is not included in a `renku` commit yet), they should revert commit the respective auto-pr so it doesn't accidentally get included in a release. *Alternatively, flag if somehow that `renku` is in an unreleasable state?* If the faulty version was already included in an overall release, make a hotfix release (turn the hotfix auto-pr in a release-pr).

Make a canary action that runs acceptance tests on all `master` (or `develop` for `rp`) branches of all repositories, to catch compatibility issues early. KG would need to install RP from source for this.

If a regression makes it through acceptance tests, a new test MUST be written for it.

### Additional things to consider

Components should strive to be independent of each other, to not create long dependency chains. E.g. core-service has API-versioning so endpoints can be added/modified without breaking downstream clients. KG should use core-service for triples instead of including it internally to benefit from API versioning. Unless there is a fundamental change in contracts, it should be possible to make releases that don't affect other components. In the case where two components need to release together, they do so by combining their auto-prs and merging them to master at the same time, NOT in the release-PR.

We might want to add some metrics like # of failures for each released version, platform and component, so sudden upticks in errors can be detected early. This should be an automated process.