aRustyDev / aRustyDev/helm-charts
feat(W5): Handle complex version bump edge cases
- Dominant language
- Go Template
- Stars
- 0
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
## Summary
W5's version bump logic now correctly uses `main`'s version as the baseline for calculating the expected version. However, there are edge cases that need further consideration.
## Current Logic (Implemented)
```
1. Fetch version from origin/main → BASE_VERSION
2. Analyze PR commits for bump type → BUMP_TYPE
3. Calculate: BASE_VERSION + BUMP_TYPE → EXPECTED_VERSION
4. Compare with PR branch version
5. If different, update and commit
```
## Edge Cases (Not Yet Handled)
### 1. Concurrent PRs for Same Chart
**Scenario:**
- PR #1 and PR #2 both modify `charts/foo`
- Main has `foo` at v1.0.0
- Both PRs calculate expected version as v1.0.1
- PR #1 merges first, main now has v1.0.1
- PR #2's W5 runs but its expected version is stale
**Current Behavior:** PR #2 would try to set v1.0.1 (conflict)
**Desired Behavior:** PR #2 should detect that main changed and recalculate to v1.0.2
### 2. Rebase After Main Updates
**Scenario:**
- PR created when main has v1.0.0
- Another PR merges, bumping main to v1.0.1
- User rebases PR on main
- W5 runs but may have cached/stale base version
**Current Behavior:** Should work correctly since we fetch from origin/main
**Verification Needed:** Confirm `git show origin/main:...` gives post-rebase version
### 3. Manual Version Bump Conflicts
**Scenario:**
- Contributor manually bumps version to v2.0.0 (major)
- Commits are `fix:` type (would calculate patch)
- W5 calculates v1.0.1 but PR has v2.0.0
**Current Behavior:** W5 would "fix" version to v1.0.1, overwriting manual bump
**Desired Behavior:** Options:
- Trust manual bump if higher than calculated
- Warn but don't override
- Fail and require manual resolution
## Proposed Solutions
### Option A: Fail on Conflict
If main's version changed since PR was created, fail W5 and require rebase.
### Option B: Smart Recalculation
Detect if base version changed and recalculate automatically.
### Option C: Version Lock File
Track the "expected next version" in a file to detect conflicts early.
## Acceptance Criteria
- [ ] Document chosen approach in ADR
- [ ] Implement conflict detection
- [ ] Add tests for edge cases
- [ ] Update W5 workflow
Contributor guide
Assessment
This issue has not been assessed yet.