From cd06d13e49cbe95dafa022af42f2ffea59ce7944 Mon Sep 17 00:00:00 2001
From: aseimel <aseimel@outlook.de>
Date: Mon, 29 Jun 2026 19:47:50 +0200
Subject: [PATCH] Document release versioning rules

---
 README.md  |  2 ++
 RELEASE.md | 37 +++++++++++++++++++++++++++++++++++++
 2 files changed, 39 insertions(+)
 create mode 100644 RELEASE.md

diff --git a/README.md b/README.md
index 5b033f5..b3b4fc1 100644
--- a/README.md
+++ b/README.md
@@ -2,6 +2,8 @@
 
 This folder contains a Windows GUI installer for OpenCode Desktop that configures the GESIS AI Server provider.
 
+Release/versioning rules are documented in `RELEASE.md`. In short: use simple tags such as `v1`, `v2`, `v3`, and only create a new tag when the distributable EXE changes and the project owner explicitly approves the bump.
+
 The installer:
 
 - downloads the latest Windows x64 OpenCode Desktop release from `anomalyco/opencode`
diff --git a/RELEASE.md b/RELEASE.md
new file mode 100644
index 0000000..7fd0b4b
--- /dev/null
+++ b/RELEASE.md
@@ -0,0 +1,37 @@
+# Release and Versioning Rules
+
+This project uses simple internal release tags:
+
+```text
+v1
+v2
+v3
+...
+```
+
+Do not use semantic version tags such as `v1.0.0`.
+
+## Hard Rules
+
+- A new version tag must only be created when the distributable `GESIS-OpenCode-Installer.exe` has changed.
+- A new version tag must only be created after explicit approval from the project owner.
+- Do not create a new tag just to change documentation, metadata, release notes, CI files, or GitLab release-page configuration.
+- Do not create a new tag just because a previous tag needs a GitLab Release page. Attach the release page to the existing tag instead.
+- Never skip numbers or create speculative tags.
+- Never delete or move an already-published tag unless the project owner explicitly asks for it.
+
+## Release Checklist
+
+1. Rebuild `GESIS-OpenCode-Installer.exe` from the current source.
+2. Verify the EXE opens and the installer workflow still works.
+3. Verify the installer still resolves the latest OpenCode Desktop release at runtime.
+4. Verify no private API key or SSH private key is present in tracked files.
+5. Commit the changed source and EXE.
+6. Ask the project owner to approve the next version number.
+7. Create the next simple tag, for example `v3`.
+8. Push `main` and the approved tag.
+9. If needed, create or update the GitLab Release page for that exact tag.
+
+## Current Policy
+
+The current release tag is the authoritative downloadable version. GitLab Release pages must point to an existing approved tag and must not cause a new tag by themselves.