Added Release Pipeline

README.md

@@ -46,6 +46,32 @@ make -f Makefile.standalone
 Contributors and AI agents should read [`AGENTS.md`](AGENTS.md) for the concise
 architecture map, invariants, and validation checklist.
 
+## Automated releases
+
+Every push to `main` runs `.gitea/workflows/release.yaml`. It builds with pinned
+OpenWrt SDKs and publishes `openUniFi-<architecture>-<version>.apk` for x64,
+x86, arm64, arm32, and mpc85xx. The workflow uses Gitea's built-in
+`GITEA_TOKEN`; repository Actions settings must allow it `write` access to
+releases. A failed target leaves the release as a draft rather than publishing
+an incomplete set.
+
+Targets and the pinned OpenWrt release live in `.gitea/release-targets.json`.
+Add an object with a unique `architecture` label and a valid OpenWrt
+`target`/`subtarget` pair to extend the matrix. The generic ARM entries select
+ARMv7 and ARMv8 ABIs; use a device-specific OpenWrt target when necessary.
+
+Releases use the next available `MAJOR.MINOR.PATCH` tag. `MAJOR` and `MINOR`
+live in the release config; the workflow finds the highest existing
+`vMAJOR.MINOR.PATCH` tag and increments its patch, starting at `0` when a new
+major or minor line is introduced. For example, changing the config from `0.4`
+to `0.5` makes the next release `0.5.0`. Release runs are serialized so two
+merges cannot select the same patch version.
+
+Alternatives are Conventional Commits with a semantic-release tool (best when
+not every merge must release), or a manually maintained `VERSION` file bumped
+in every pull request (simple, but a forgotten bump blocks the release). Change
+`major` for incompatible changes and `minor` for compatible features.
+
 ## Changing Compiler Settings
 
 ```shell