3.6The Conditional Release Compromise

In practice, most release decisions are not binary (ship / do not ship). The most common and productive outcome is a conditional release -- shipping with known issues and an explicit mitigation plan.

Elements of a Conditional Release Agreement

Release: v2.4.0
Date: March 15, 2025
Status: CONDITIONAL RELEASE

Known Issues Shipping:
1. BUG-1207: Price displays as $0.00 for bundled items
   - Mitigation: Server-side price validation prevents $0 orders
   - Fix ETA: Hotfix within 48 hours
   - Monitoring: Alert on any order with $0 line items

2. BUG-1215: Discount code applied twice in edge case
   - Mitigation: Manual review of discounted orders > 30%
   - Fix ETA: Sprint 25
   - Monitoring: Daily report of orders with > 1 discount application

Conditions for Emergency Rollback:
- More than 50 affected transactions in 1 hour
- Any data integrity issue (double charges, lost orders)
- Any security vulnerability discovered

Monitoring Owner: [QA Engineer Name]
Rollback Owner: [DevOps Engineer Name]
Incident Commander: [Engineering Manager Name]

Why Conditional Releases Work

• They acknowledge that perfection is not always possible or necessary
• They create accountability by documenting who knows what and who owns what
• They satisfy business needs (ship the feature) while managing risk (monitor and fix)
• They build trust because QA is seen as pragmatic, not obstructionist