Add "lessons/sprints/v400-release---wiki-workflow-and-versioning-patterns"
@@ -0,0 +1,150 @@
|
||||
# Lessons Learned: v4.0.0 Release
|
||||
|
||||
**Date:** 2026-01-25
|
||||
**Version:** v4.0.0
|
||||
**Scope:** data-platform plugin release + wiki workflow establishment
|
||||
|
||||
---
|
||||
|
||||
## Lesson 1: Wiki-Based Change Proposal Workflow
|
||||
|
||||
### Context
|
||||
Needed to document the v4.0.0 implementation plan and preserve planning rationale beyond issue creation.
|
||||
|
||||
### Pattern Established
|
||||
```
|
||||
Wiki Structure:
|
||||
- "Change VXX.X.X: Proposal" - Original architecture/design reference
|
||||
- "Change VXX.X.X: Proposal (Implementation N)" - Specific implementation plan
|
||||
|
||||
Tags for Proposals:
|
||||
> **Type:** Change Proposal
|
||||
> **Version:** VXX.X.X
|
||||
> **Status:** Pending | In Progress | Implemented
|
||||
> **Date:** YYYY-MM-DD
|
||||
|
||||
Tags for Implementations:
|
||||
> **Type:** Change Proposal Implementation
|
||||
> **Version:** VXX.X.X
|
||||
> **Status:** Implemented
|
||||
> **Date:** YYYY-MM-DD
|
||||
> **Origin:** [link to proposal]
|
||||
```
|
||||
|
||||
### Benefit
|
||||
- Separates planning docs from project documentation
|
||||
- Creates traceability chain: Proposal → Implementation → Issues → Lessons
|
||||
- Supports multiple implementations per proposal
|
||||
|
||||
---
|
||||
|
||||
## Lesson 2: Release Script Requires Clean Working Directory
|
||||
|
||||
### Problem
|
||||
`./scripts/release.sh 4.0.0` failed because `.claude/` directory (local settings) was untracked.
|
||||
|
||||
### Solution
|
||||
Either:
|
||||
1. Add `.claude/` to `.gitignore` (preferred)
|
||||
2. Perform version updates manually when script fails
|
||||
|
||||
### Manual Steps
|
||||
```bash
|
||||
# 1. Update CHANGELOG.md: [Unreleased] → [X.Y.Z] - YYYY-MM-DD
|
||||
# 2. Update README.md title
|
||||
# 3. Update marketplace.json version
|
||||
# 4. Commit and tag
|
||||
```
|
||||
|
||||
### Prevention
|
||||
Add `.claude/` to `.gitignore` in the repository.
|
||||
|
||||
---
|
||||
|
||||
## Lesson 3: Protected Branch Requires PR for Version Bumps
|
||||
|
||||
### Problem
|
||||
Direct push to `development` branch failed with "Not allowed to push to protected branch".
|
||||
|
||||
### Solution
|
||||
Even version bump commits need a PR:
|
||||
```bash
|
||||
git checkout -b chore/release-vX.Y.Z
|
||||
git push -u origin chore/release-vX.Y.Z
|
||||
# Create PR via API or web
|
||||
```
|
||||
|
||||
### Note
|
||||
This is correct behavior - all changes should go through PR review.
|
||||
|
||||
---
|
||||
|
||||
## Lesson 4: Git Tag Timing Matters
|
||||
|
||||
### Problem
|
||||
Created tag before PR merge, pointing to wrong commit. Then tag already existed when trying to recreate.
|
||||
|
||||
### Solution
|
||||
```bash
|
||||
# Delete local tag
|
||||
git tag -d vX.Y.Z
|
||||
|
||||
# Create tag at merge commit (after PR merge)
|
||||
git tag -a vX.Y.Z -m "Release vX.Y.Z - description"
|
||||
|
||||
# Push tag
|
||||
git push origin vX.Y.Z
|
||||
```
|
||||
|
||||
### Prevention
|
||||
Always create tags AFTER the PR is merged, pointing to the merge commit.
|
||||
|
||||
---
|
||||
|
||||
## Lesson 5: MCP Tool Gap - No PR Creation
|
||||
|
||||
### Problem
|
||||
Gitea MCP server has `list_pull_requests`, `get_pull_request`, `create_pr_review`, but no `create_pull_request` tool.
|
||||
|
||||
### Workaround
|
||||
Used curl with Gitea API directly:
|
||||
```bash
|
||||
curl -X POST "https://gitea.example.com/api/v1/repos/owner/repo/pulls" \
|
||||
-H "Authorization: token $GITEA_API_TOKEN" \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{"title": "...", "head": "branch", "base": "development", "body": "..."}'
|
||||
```
|
||||
|
||||
### Future Improvement
|
||||
Consider adding `create_pull_request` tool to Gitea MCP server.
|
||||
|
||||
---
|
||||
|
||||
## Lesson 6: Version Naming Convention
|
||||
|
||||
### Pattern
|
||||
Wiki pages use zero-padded version format: `V04.0.0` (capital V, two-digit major)
|
||||
|
||||
### Examples
|
||||
- `Change V04.0.0: Proposal` (not `v4.0.0`)
|
||||
- `Change V03.2.0: Proposal`
|
||||
|
||||
### Reason
|
||||
Ensures proper alphabetical sorting in wiki page list.
|
||||
|
||||
---
|
||||
|
||||
## Summary
|
||||
|
||||
| Lesson | Category | Impact |
|
||||
|--------|----------|--------|
|
||||
| Wiki workflow for proposals | Process | High - establishes documentation pattern |
|
||||
| Release script clean dir | Tooling | Low - workaround available |
|
||||
| Protected branch PRs | Process | Normal - correct behavior |
|
||||
| Tag after merge | Git | Medium - prevents tag conflicts |
|
||||
| No PR creation MCP tool | Tooling | Low - API workaround works |
|
||||
| Version naming V0X.X.X | Convention | Medium - wiki organization |
|
||||
|
||||
|
||||
---
|
||||
**Tags:** versioning, wiki, release-workflow, git-tags, protected-branches, mcp-tools, data-platform
|
||||
Reference in New Issue
Block a user