mirror of
https://github.com/AyuGram/AyuGramDesktop.git
synced 2026-07-25 06:54:43 +00:00
John Preston
117 lines
4.8 KiB
Markdown
117 lines
4.8 KiB
Markdown
---
|
|
description: Prepare changelog, set version, and commit a new release
|
|
allowed-tools: Read, Bash, Edit, Grep, AskUserQuestion
|
|
---
|
|
|
|
# Release — Changelog, Set Version, Commit
|
|
|
|
Full release flow: generate changelog entry, run `set_version`, and commit.
|
|
|
|
**Arguments:** `$ARGUMENTS` = "$ARGUMENTS"
|
|
|
|
Parse `$ARGUMENTS` for two optional parts (in any order):
|
|
- A **version number** like `6.7` or `6.7.0` — if provided, use it as the new version exactly.
|
|
- The word **"beta"** — if present, mark the release as beta.
|
|
|
|
If no version number is given, auto-increment the patch component (see step 2).
|
|
|
|
## Steps
|
|
|
|
### 1. Check git status is clean
|
|
|
|
Run `git status --porcelain`. If there are any uncommitted changes, **stop** and ask the user to commit or discard them before proceeding. Do not continue until status is clean.
|
|
|
|
### 2. Read the current changelog
|
|
|
|
Read `changelog.txt` from the repository root. Note the **latest version number** on the first line (e.g. `6.6.3 beta (12.03.26)`). Parse its major.minor.patch components.
|
|
|
|
### 3. Determine the new version number
|
|
|
|
- **If a version was provided in arguments**, use it directly (append `.0` if only major.minor was given).
|
|
- **If no version was provided**, auto-increment from the latest changelog version:
|
|
- If it was a beta, and the new release is **not** beta, reuse the same version number but drop "beta".
|
|
- If the new release is beta and the latest was also beta with the same major.minor, bump patch.
|
|
- Otherwise bump the patch component by 1.
|
|
- Present the chosen version to the user and ask for confirmation before proceeding. If the user suggests a different version, use that instead.
|
|
|
|
### 4. Fetch tags and determine the last release tag
|
|
|
|
Run `git fetch origin --tags` first to ensure all tags from the public repository are available locally. Then run `git tag --sort=-v:refname` and find the most recent `v*` tag. This is the baseline for the diff.
|
|
|
|
### 5. Collect commits
|
|
|
|
Run `git log <last-tag>..HEAD --oneline` to get all commits since the last release.
|
|
|
|
### 6. Write the changelog entry
|
|
|
|
Analyze every commit message. Group them mentally into features, improvements, and bug fixes. Then produce **brief, user-facing bullet points** following these rules:
|
|
|
|
- **Style:** Match the existing changelog tone exactly — short, imperative sentences starting with a verb (Fix, Add, Allow, Show, Improve, Support…). Keep the trailing periods (the existing changelog uses them).
|
|
- **Brevity:** Each bullet should be one short sentence, around 80 characters when possible. No implementation details. No commit hashes.
|
|
- **Selection:** Only include changes that matter to end users. Skip CI, build infra, submodule bumps, code style, refactors, and intermediate WIP commits. Collapse many related commits (e.g. a dozen image-editor commits) into one or two bullets.
|
|
- **Ordering:** Features first, then improvements, then bug fixes.
|
|
- **Quantity:** Aim for 4-12 bullets total depending on the amount of changes.
|
|
|
|
### 7. Format and insert into changelog.txt
|
|
|
|
Use this exact format (date is today in DD.MM.YY):
|
|
|
|
```
|
|
<version> [beta ](DD.MM.YY)
|
|
|
|
- Bullet one.
|
|
- Bullet two.
|
|
```
|
|
|
|
Prepend the new entry at the very top of `changelog.txt`, separated by a blank line from the previous first entry. Use the Edit tool.
|
|
|
|
### 8. Show the entry and wait for approval
|
|
|
|
Print the full changelog entry in chat and ask the user to review it. Tell them they can:
|
|
- Approve as-is.
|
|
- Edit `changelog.txt` directly in the IDE and tell you to continue.
|
|
- Tell you what to change in chat.
|
|
|
|
**Do NOT proceed until the user explicitly approves.** If they request changes, apply them and show the updated entry again.
|
|
|
|
### 9. Run set_version
|
|
|
|
Once approved, run the `set_version` script from the repository root. On Windows:
|
|
|
|
```
|
|
.\Telegram\build\set_version.bat <version_arg>
|
|
```
|
|
|
|
Where `<version_arg>` is formatted as the `set_version` script expects:
|
|
- Stable: `6.7.0` or `6.7`
|
|
- Beta: `6.7.0.beta`
|
|
|
|
Verify the script exits successfully (exit code 0). If it fails, show the error and stop.
|
|
|
|
### 10. Commit
|
|
|
|
Stage all changes and create a commit. The commit message format:
|
|
|
|
**First line:**
|
|
- For stable: `Version <major>.<minor>.` if patch is 0, otherwise `Version <major>.<minor>.<patch>.`
|
|
- For beta: `Beta version <major>.<minor>.<patch>.`
|
|
|
|
**Then an empty line, then the changelog bullets.** Each bullet line (starting with `- `) must be wrapped at around 77-78 characters. When wrapping, break at logically correct places (between words/phrases) and indent continuation lines with two spaces.
|
|
|
|
Example commit message:
|
|
```
|
|
Beta version 6.6.3.
|
|
|
|
- Drawing tools in image editor
|
|
(brush, marker, eraser, arrow).
|
|
- Draw-to-reply button in media viewer.
|
|
- Trim recorded voice messages.
|
|
- Fix reorder freeze in chats list.
|
|
```
|
|
|
|
Use a HEREDOC to pass the message to `git commit -a`.
|
|
|
|
### 11. Done
|
|
|
|
Run `git log -1` to show the resulting commit and confirm success.
|