# Releasing the AURA software bundle

The release of a complete software bundle is triggered from within the `aura` repository and
**performed by the release manager**.

Before proceeding review the main AURA changelog in `aura/CHANGELOG.md`.

## Preparing the release

1. Create a new branch for the release: `git checkout -b %VERSION%-prep`. Note the `-prep` suffix
   for release preparation, as the actual `%VERSION%` branch needs to stay unused for the actual
   release tag branch.
2. In `aura/CHANGELOG.md` change the version identifier `[Unreleased]` to the release version and
   add the current date.
3. Bump the version of the `aura` repository with `poetry version <version>`.
4. Update the versions of referenced services in the _Docker Compose_ `config/<docker compose>/sample.env`
   files and in `scripts/dev/.env`.
5. Update the configuration files, fixtures, contributors and changelogs by running

   ```bash
   cd scripts/dev && make release.prepare
   ```

   This command pulls all configuration files, fixtures and changelogs from the individual repos
   identified by the versions in `scripts/dev/.env`. The changlogs are stored `.tmp` and are merged
   into a file named `merged-CHANGELOG-%AURA_VERSION%.md`. Commit any changed configs and fixtures.
   Review the collected contributors and update their types of contributions. Add missing ones
   manually (see [Adding a contributor manually](#adding-a-contributor-manually)).

6. Commit and push the branch.

Now inform the testers to check-out and test the given branch.

## Adding a contributor manually

Contributors are automatically added to the contributors list by the `release.prepare` Makefile
target. In case you need to add a contributor manually, use the Makefile target from `scripts/dev`:

```bash
cd scripts/dev
export GITLAB_PRIVATE_TOKEN=<token> # Alternatively set the token in the .env file
make contributors.add CONTRIBUTOR=<gitlab-username> TYPES=<contribution-types>
```

Multiple contribution types are comma-separated. See the [contribution types](https://allcontributors.org/docs/en/emoji-key)
for valid values (e.g. `code`, `doc`, `design`, `ideas`, `userTesting`).

Contributors who do not have a GitLab account can be added directly to the `.all-contributorsrc`
file.

After adding, regenerate all contributor tables:

```bash
make contributors.generate
```

## Performing the release

After the **testers inform the product owner and development team**, that the _release criteria_
is met, we can proceed.

In case developers have done any last minute bugfixes and re-released their services, ensure all
the configuration and changelog files are still up-to-date by executing

```bash
cd scripts/dev && make release.prepare
```

once more.

1. Take the contents of `.tmp/merged-CHANGELOG-%AURA_VERSION%.md` and paste it into a new section
   in `docs/release-notes.md`.
2. Now we have to start thinking: What should be in the header of the release notes? Comprehend
   what this release delivers by checking the roadmap and contents of the changelog below.
3. Review and commit the changes.
4. To ship the release, run

```bash
cd scripts/dev && make release.ship
```

5. Check out `main` and merge everything changed, except the version updates. They should remain
   as `main` for all services. Alternatively cherry-pick the
   relevant commits or update the relevant version strings to `main` after the merge.
6. Update `aura/CHANGELOG.md` with a new template section for the next release.
7. Push the changes to `main`.
8. Delete the branch used for release preparation.
9. Inform the product owner and team that the release is done.