pjt222/agent-almanac/plan-release-cycle

## Release Plan: v2.0.0
 
### Timeline
 
| Phase | Start | End | Duration | Description |
|---|---|---|---|---|
| Development | 2026-02-17 | 2026-03-14 | 4 weeks | Active feature development |
| Feature Freeze | 2026-03-15 | 2026-03-15 | 1 day | No new features merged after this date |
| Stabilization | 2026-03-15 | 2026-03-21 | 1 week | Bug fixes, documentation, testing only |
| RC1 | 2026-03-22 | 2026-03-22 | 1 day | First release candidate tagged |
| RC Testing | 2026-03-22 | 2026-03-28 | 1 week | Community/team testing of RC |
| RC2 (if needed) | 2026-03-29 | 2026-03-29 | 1 day | Second RC if critical issues found |
| Go/No-Go | 2026-03-31 | 2026-03-31 | 1 day | Final decision meeting |
| Release | 2026-04-01 | 2026-04-01 | 1 day | Tag, publish, announce |

### Feature Freeze Criteria
 
After feature freeze (2026-03-15):
-**Allowed**: Bug fixes, test additions, documentation updates, dependency security patches
-**Not allowed**: New features, API changes, refactoring, dependency upgrades (non-security)
-**Exception process**: Feature freeze exceptions require written justification and approval from [release owner]
 
### Feature Priority List
| Priority | Feature | Status | Owner | Notes |
|---|---|---|---|---|
| P0 (must) | New export format | In progress | [Name] | Blocks release |
| P0 (must) | Security audit fixes | Not started | [Name] | Compliance requirement |
| P1 (should) | Performance optimization | In progress | [Name] | Defer if not ready |
| P2 (nice) | Dark mode support | Not started | [Name] | Defer to v2.1.0 if needed |

### Release Candidate Process
 
1. **RC1 Tag**: Tag from the stabilization branch after all P0 features merged and CI green
   ```bash
   git tag -a v2.0.0-rc.1 -m "Release candidate 1 for v2.0.0"
   ```
 
2. **RC Distribution**: Publish RC to staging/testing channel
   - R: `install.packages("pkg", repos = "https://staging.r-universe.dev/user")`
   - Node.js: `npm install pkg@next`
   - Internal: Deploy to staging environment
 
3. **RC Testing Period**: 5-7 business days
   - Run full test suite including integration tests
   - Verify all P0 features work as documented
   - Test upgrade path from previous version
   - Check for regressions in existing functionality
 
4. **RC Evaluation**:
   - **No critical/high bugs**: Proceed to release
   - **Critical bugs found**: Fix, tag RC2, restart testing period
   - **More than 2 RCs needed**: Revisit scope and timeline
 
5. **RC2+ Tags**: Only if critical issues found in previous RC
   ```bash
   git tag -a v2.0.0-rc.2 -m "Release candidate 2 for v2.0.0"
   ```

### Go/No-Go Checklist
 
#### Must Pass (release blocked if any fail)
-[ ] All CI checks passing on release branch
-[ ] Zero critical bugs open against this version
-[ ] Zero high-severity security vulnerabilities
-[ ] All P0 features verified and documented
-[ ] Changelog complete and reviewed
-[ ] Upgrade path tested from previous version (v1.x -> v2.0.0)
-[ ] License and attribution files up to date
 
#### Should Pass (release proceeds with documented risk)
-[ ] Zero high bugs open (non-critical)
-[ ] All P1 features included
-[ ] Performance benchmarks within acceptable range
-[ ] Documentation reviewed and spell-checked
-[ ] External dependencies at latest stable versions
 
#### Decision
-**Go**: All "Must Pass" items checked, majority of "Should Pass" items checked
-**No-Go**: Any "Must Pass" item unchecked
-**Conditional Go**: All "Must Pass" checked, significant "Should Pass" items unchecked — document accepted risks

### Rollback Plan
 
#### Rollback Triggers
-Critical bug affecting >10% of users
-Data corruption or loss
-Security vulnerability introduced by the release
-Breaking change not documented in changelog
 
#### Rollback Procedure
1.**Revert package registry**: Unpublish or yank the release
   -R/CRAN: Contact CRAN maintainers (cannot self-unpublish)
   -npm: `npm unpublish pkg@2.0.0` (within 72 hours)
   -GitHub: Mark release as pre-release, publish point fix
 
2.**Communicate**: Notify users via GitHub issue, mailing list, or social channels
   -Template: "v2.0.0 has been rolled back due to [issue]. Please use v1.x.y until a fix is released."
 
3.**Fix forward**: Prefer a v2.0.1 patch release over a full rollback when possible
 
4.**Post-mortem**: Conduct a post-mortem within 48 hours of rollback to identify process gaps
 
#### Point Release Policy
-v2.0.1 for critical bug fixes within 1 week of release
-v2.0.2 for additional fixes within 2 weeks
-Patch releases do not require full RC cycle but must pass CI and critical test suite