aseimel
38 lines
1.5 KiB
Markdown
38 lines
1.5 KiB
Markdown
# 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.
|