Files
EOS/docs/develop/release.md
Bobby Noelte 976a2c8405
Some checks failed
Bump Version / Bump Version Workflow (push) Has been cancelled
docker-build / platform-excludes (push) Has been cancelled
docker-build / build (push) Has been cancelled
docker-build / merge (push) Has been cancelled
pre-commit / pre-commit (push) Has been cancelled
Run Pytest on Pull Request / test (push) Has been cancelled
chore: automate development version and release generation (#772)
This change introduces a GitHub Action to automate release creation, including
proper tagging and automatic addition of a development marker to the version.

A hash is also appended to development versions to make their state easier to
distinguish.

Tests and release documentation have been updated to reflect the revised
release workflow. Several files now retrieve the current version dynamically.

The test --full-run option has been rename to --finalize to make
clear it is to do commit finalization testing.

Signed-off-by: Bobby Noelte <b0661n0e17e@gmail.com>
2025-11-20 00:10:19 +01:00

3.5 KiB
Raw Blame History

% SPDX-License-Identifier: Apache-2.0 (release-page)=

Release Process

This document describes how to prepare and publish a new release via a Pull Request from a fork, and how to set a development version after the release.

Overview of the Process

Step Actor Action
1 Contributor Prepare a release branch in your fork using Commitizen
2 Contributor Open a Pull Request to upstream (Akkudoktor-EOS/EOS)
3 Maintainer Review and merge the release PR
4 CI Create the GitHub Release and tag
5 CI Set the development version marker via a follow-up PR

🔄 Detailed Workflow

1 Contributor: Prepare the Release in Your Fork

Clone and sync your fork

git clone https://github.com/<your-username>/EOS
cd EOS
git remote add eos https://github.com/Akkudoktor-EOS/EOS

git fetch eos
git checkout main
git pull eos main

Create the release branch

git checkout -b release/vX.Y.Z

Bump the version information

Set __version__ in src/akkudoktoreos/core/version.py

__version__ = 0.3.0

Prepare version by updating versioned files, e.g.:

  • haaddon/config.yaml

and the generated documentation:

make prepare-version

Check the changes by:

make test-version

Create a new CHANGELOG.md entry

Edit CHANGELOG.md

Create the new release commit

Add all the changed version files and all other changes to the commit.

git add src/akkudoktoreos/core/version.py CHANGELOG.md ...
git commit -s -m "chore: Prepare Release v0.3.0"

Push the branch to your fork

git push --set-upstream origin release/v0.3.0

2 Contributor: Open the Release Preparation Pull Request

From To
<your-username>/EOS:release/vX.Y.Z Akkudoktor-EOS/EOS:main

PR Title:

chore: prepare release vX.Y.Z

PR Description Template:

## Prepare Release vX.Y.Z

This pull request prepares release **vX.Y.Z**.

### Changes
- Version bump
- Changelog update

### Changelog Summary
<!-- Copy key highlights from CHANGELOG.md here -->

See `CHANGELOG.md` for full details.

3 Maintainer: Review and Merge the Release PR

Review Checklist:

  • Only version files and CHANGELOG.md are modified
  • Version numbers are consistent
  • Changelog is complete and properly formatted
  • No unrelated changes are included

Merge Strategy:

  • Prefer Merge Commit (or Squash Merge, per project preference)
  • Use commit message: chore: Prepare Release vX.Y.Z

4 CI: Publish the GitHub Release

The new release will automatically be published by the GitHub CI action.

See .github/workflwows/bump-version.ymlfor details.

5 CI: Prepare the Development Version Marker

The development version marker will automatically be set by the GitHub CI action.

See .github/workflwows/bump-version.ymlfor details.

Quick Reference

Step Actor Action
1. Prepare release branch Contributor Bump version & changelog
2. Open release PR Contributor Submit release for review
3. Review & merge release PR Maintainer Finalize changes into main
4. Publish GitHub Release CI Create tag & notify users
5. Prepare development version branch CI Set development marker