armin/opencode_gesis
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity

Document release versioning rules

Browse Source
This commit is contained in:
aseimel
2026-06-29 19:47:50 +02:00
parent 1f819694af
commit cd06d13e49
2 changed files with 39 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+2
View File
@@ -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`
RELEASE.md
+37
View File
@@ -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.