|
| 1 | +# Release Process |
| 2 | + |
| 3 | +This document describes how releases are managed for OpenAstroTracker-Firmware. It is intended for project developers with write access to the repository. |
| 4 | + |
| 5 | +## Overview |
| 6 | + |
| 7 | +Releases are fully automated via [release-please](https://github.com/googleapis/release-please). The process requires no manual version bumping or changelog editing — both are driven by PR titles following the [Conventional Commits](https://www.conventionalcommits.org/) specification. |
| 8 | + |
| 9 | +``` |
| 10 | +PR merged → release-please updates its Release PR → maintainer merges Release PR → tag + GitHub Release created automatically |
| 11 | +``` |
| 12 | + |
| 13 | +## Conventional Commits (required for all PRs) |
| 14 | + |
| 15 | +Every PR title **must** follow this format: |
| 16 | + |
| 17 | +``` |
| 18 | +<type>: <short description> |
| 19 | +``` |
| 20 | + |
| 21 | +CI will reject PR titles that do not conform. |
| 22 | + |
| 23 | +| Type | Triggers | Example | |
| 24 | +|------|----------|---------| |
| 25 | +| `feat` | minor version bump | `feat: add AZ/ALT steps-per-degree Meade command` | |
| 26 | +| `fix` | patch version bump | `fix: correct sidereal rate after meridian flip` | |
| 27 | +| `feat!` or `BREAKING CHANGE:` footer | major version bump | `feat!: remove legacy serial protocol` | |
| 28 | +| `chore` | no version bump | `chore: update platformio dependencies` | |
| 29 | +| `docs` | no version bump | `docs: clarify wiring diagram for RAMPS` | |
| 30 | +| `refactor` | no version bump | `refactor: extract stepper configuration logic` | |
| 31 | +| `test` | no version bump | `test: add unit tests for DayTime rollover` | |
| 32 | +| `ci` | no version bump | `ci: update clang-format action version` | |
| 33 | +| `perf` | no version bump | `perf: reduce interrupt latency in stepper ISR` | |
| 34 | + |
| 35 | +The description becomes the changelog entry, so write it as a user-facing statement of what changed — not what you did internally. |
| 36 | + |
| 37 | +## How release-please Works |
| 38 | + |
| 39 | +After each PR is merged into `develop`, the `release-please` GitHub Action updates an open **Release PR**. This PR: |
| 40 | + |
| 41 | +- Accumulates all `feat`, `fix`, and other notable commits since the last release |
| 42 | +- Proposes the next semantic version (patch / minor / major based on commit types) |
| 43 | +- Updates `Changelog.md` with categorised entries linked to PRs |
| 44 | +- Updates `Version.h` with the new version string |
| 45 | + |
| 46 | +The Release PR stays open and self-updates as more PRs are merged. When you are ready to cut a release, simply **merge the Release PR**. |
| 47 | + |
| 48 | +## Cutting a Release |
| 49 | + |
| 50 | +1. Review the open Release PR (titled `chore(main): release V<version>`) — check the proposed version and changelog entries. |
| 51 | +2. Merge it into `develop`. |
| 52 | +3. `release-please` automatically: |
| 53 | + - Creates a git tag `V<version>` (e.g. `V1.14.0`) |
| 54 | + - Publishes a GitHub Release with the generated changelog |
| 55 | + |
| 56 | +No manual tag pushing, no manual `Version.h` edits. |
| 57 | + |
| 58 | +## Version Semantics |
| 59 | + |
| 60 | +Versions follow [Semantic Versioning](https://semver.org/) (`MAJOR.MINOR.PATCH`): |
| 61 | + |
| 62 | +| Change | Bump | |
| 63 | +|--------|------| |
| 64 | +| Breaking change in Meade protocol or configuration | **Major** | |
| 65 | +| New feature, new board support, new Meade command | **Minor** | |
| 66 | +| Bug fix, performance improvement, documentation | **Patch** | |
| 67 | +| Chore, CI, refactor, test | **None** | |
| 68 | + |
| 69 | +## CI Checks on Every PR |
| 70 | + |
| 71 | +All of the following must pass before a PR can be merged: |
| 72 | + |
| 73 | +| Check | What it validates | |
| 74 | +|-------|------------------| |
| 75 | +| **PR Title (Conventional Commits)** | PR title follows `<type>: <description>` format | |
| 76 | +| **Unit Tests** | `pio test -e native` passes | |
| 77 | +| **Build (mksgenlv21)** | Firmware compiles for MKS Gen L V2.1 | |
| 78 | +| **Build (mksgenlv2)** | Firmware compiles for MKS Gen L V2 | |
| 79 | +| **Build (mksgenlv1)** | Firmware compiles for MKS Gen L V1 | |
| 80 | +| **Build (esp32)** | Firmware compiles for ESP32 | |
| 81 | +| **Build (ramps)** | Firmware compiles for RAMPS | |
| 82 | +| **clang-format** | Code formatting matches `.clang-format`; auto-fixed on same-repo branches | |
| 83 | + |
| 84 | +## Firmware Binaries |
| 85 | + |
| 86 | +Pre-built binaries are **not** published in GitHub Releases. Because the firmware is configured via generated header files (stepper drivers, sensors, display type, etc.), a generic binary would not be usable without recompilation. Users must build the firmware for their specific hardware configuration using PlatformIO. |
| 87 | + |
| 88 | + |
0 commit comments