chore: add release-manager agent and move release docs (#110)
Create dedicated GitHub Copilot agent for release management with 4 tasks: branch/PR workflow, version determination, release execution, and release notes writing. Move release-specific instructions (workflow, release notes format, breaking changes) from copilot-instructions.md to the agent file to keep concerns separated.
This commit is contained in:
Daniel Volz
GitHub
@@ -180,141 +180,6 @@ gh pr merge --squash --delete-branch
|
||||
| `.github/workflows/test.yml` | Pull Requests | Run tests, block PR on failures |
|
||||
| `.github/workflows/docker-build.yml` | Push to main, Tags | Tests + Build and push Docker images |
|
||||
|
||||
### Adding New Code - Checklist
|
||||
1. ✅ Implement feature
|
||||
2. ✅ Write tests for the feature
|
||||
3. ✅ Run `npm run test:coverage` locally
|
||||
4. ✅ Coverage must not decrease
|
||||
5. ✅ Create and push feature branch
|
||||
6. ✅ Create Pull Request
|
||||
7. ✅ Wait until CI is green
|
||||
8. ✅ Merge PR (branch is automatically deleted)
|
||||
|
||||
## GitHub Releases
|
||||
|
||||
> ⚠️ **IMPORTANT**: All GitHub Releases must be written in **English**!
|
||||
|
||||
### Release Workflow (MANDATORY for minor/major releases)
|
||||
|
||||
The `main` branch is protected - releases are created via GitHub's release UI or API.
|
||||
|
||||
**Release Process:**
|
||||
1. Create a new release on GitHub with tag `vX.Y.Z`
|
||||
2. **Automatic Version Bump**: A GitHub Action (`version-bump.yml`) automatically updates `package.json` versions to match the release tag
|
||||
3. User asks AI to write release notes: "Write the release notes for vX.Y.Z"
|
||||
4. AI writes descriptive release notes following the style guide below
|
||||
5. User publishes the release with the written notes
|
||||
|
||||
> ⚠️ **MANDATORY for minor and major releases**: The AI assistant MUST write proper descriptive release notes!
|
||||
> Do NOT just publish the auto-generated commit list. Follow the process above.
|
||||
|
||||
**AI Assistant Release Notes Workflow:**
|
||||
1. When user asks to write release notes for a version:
|
||||
- Check commits since previous tag: `git log vPREV..vNEW --oneline`
|
||||
- Read through the changes to understand what was added/fixed
|
||||
- Write release notes following the style guide below
|
||||
- Present the notes to the user for copying to GitHub
|
||||
|
||||
### Creating Release Notes
|
||||
|
||||
> ⚠️ **MANDATORY**: GitHub Releases MUST contain a written message!
|
||||
> Not just auto-generated commit lists, but a brief descriptive text.
|
||||
|
||||
**Release title:** Use just `vX.Y.Z` (e.g., `v1.4.1`), NOT "Release vX.Y.Z".
|
||||
|
||||
**Keep it informative but concise.** Users want to know what changed and where to find it.
|
||||
|
||||
**Required structure of release notes:**
|
||||
|
||||
1. **"What's New"** (1-2 sentences): Brief intro explaining the main change
|
||||
2. **"New Features" / "Improvements"**: Grouped bullet points with **bold feature names** and descriptions
|
||||
3. **"Where to Find It"**: Tell users where they can access the new feature
|
||||
4. **Breaking Changes Warning** (if applicable): See below
|
||||
|
||||
**Style guidelines:**
|
||||
- Use `### Heading` for sections (New Features, Improvements, Security, etc.)
|
||||
- Use **bold** for feature names in bullet points
|
||||
- Keep descriptions on the same line as the feature name
|
||||
- Minimal emoji usage (sparingly, not on every line)
|
||||
- Always end with "Where to Find It" section
|
||||
|
||||
**DO NOT include:**
|
||||
- ❌ Technical implementation details (new columns, endpoints, database changes)
|
||||
- ❌ Number of tests added
|
||||
- ❌ Internal API changes (unless breaking)
|
||||
- ❌ Excessive emoji on every bullet point
|
||||
- ❌ .gitignore changes or other developer-only file changes
|
||||
- ❌ AI/Copilot instruction updates
|
||||
- ❌ CI/CD workflow changes (unless affecting users)
|
||||
- ❌ Code refactoring without user-visible changes
|
||||
|
||||
**Only include user-relevant changes** - things that affect what users see or experience in the app.
|
||||
|
||||
**Example of good release notes:**
|
||||
|
||||
```markdown
|
||||
## What's New
|
||||
|
||||
This release introduces a medication refill tracking feature and improves the mobile user experience.
|
||||
|
||||
### New Features
|
||||
|
||||
- **Medication Refill**: Track when you refill your medications with a single click. Add full packs or individual pills and view complete refill history.
|
||||
- **Automatic Stock Updates**: Stock levels are automatically recalculated after each refill.
|
||||
- **Refill History**: Each medication shows a complete history of all refills with timestamps.
|
||||
|
||||
### Mobile Improvements
|
||||
|
||||
- **Centered Tooltips**: Info tooltips now display centered on screen for better readability.
|
||||
- **Touch-friendly**: Tooltips close automatically when scrolling on touch devices.
|
||||
|
||||
### Where to Find It
|
||||
|
||||
The refill button appears in the medication detail modal and in the edit form for each medication.
|
||||
|
||||
**Full Changelog**: https://github.com/DanielVolz/medassist-ng/compare/v1.2.3...v1.3.0
|
||||
```
|
||||
|
||||
### Breaking Changes Warning (CRITICAL!)
|
||||
|
||||
> ⚠️ **MANDATORY**: If an update breaks existing configurations or stored data, it MUST be prominently warned about in the release notes!
|
||||
|
||||
**Breaking Changes include:**
|
||||
- Database schema changes without automatic migration
|
||||
- Removed or renamed ENV variables
|
||||
- Changed API endpoints
|
||||
- Incompatible `.env` format changes
|
||||
- Loss of stored data after update
|
||||
|
||||
**Format for Breaking Changes:**
|
||||
|
||||
```markdown
|
||||
## ⚠️ BREAKING CHANGES - Please read before updating!
|
||||
|
||||
**Database migration required**: This update changes the database schema.
|
||||
Existing installations need to:
|
||||
1. Create backup of `data/` folder
|
||||
2. Stop containers
|
||||
3. Perform update
|
||||
4. If issues occur: Rollback using backup
|
||||
|
||||
**ENV variables changed**:
|
||||
- `OLD_VAR` was renamed to `NEW_VAR`
|
||||
- `REMOVED_VAR` is no longer supported
|
||||
|
||||
**Medication data**: Intake schedules with only one time entry will be automatically
|
||||
migrated. Please verify all times are correct after update.
|
||||
```
|
||||
|
||||
**What is NOT a Breaking Change:**
|
||||
- ✅ New optional columns with DEFAULT values
|
||||
- ✅ New ENV variables (with sensible defaults)
|
||||
- ✅ New features that don't affect existing data
|
||||
- ✅ Bug fixes that correct behavior
|
||||
|
||||
**Rule of thumb**: If a user can simply run `docker compose pull && docker compose up -d`
|
||||
without adjusting anything → Not a Breaking Change.
|
||||
|
||||
## Key Patterns
|
||||
|
||||
### Backend Routes (`backend/src/routes/`)
|
||||
|
||||
Reference in New Issue
Block a user