Enterprise Release Management

This guide is for B2B software companies that maintain multiple product versions for different customers.

The Enterprise Challenge

Enterprise software has unique requirements:

• Customer lock-in: Customers stay on specific versions for years
• Compliance: Regulated industries require stable, certified versions
• Support contracts: SLAs mandate bug fixes for all supported versions
• Deployment cycles: Customers have their own upgrade schedules

Common Scenarios

Scenario 1: On-Premise Software

Customers install your software in their data centers. Different customers run different versions based on when they last upgraded.

Scenario 2: SaaS with Version Options

You offer multiple SaaS versions for customers who can't adopt the latest.

Scenario 3: Regulated Industries

Healthcare, finance, government customers need certified versions that can't change except for security patches.

Branch Strategy for Enterprise

Typical Structure

main (next release development)
│
├── release-2026-q1 (current release)
├── release-2025-q4 (previous quarter)
├── release-2025-q3 (older but supported)
│
├── v5-lts (long-term support)
├── v4-lts (legacy LTS)
└── v3-lts (end-of-life soon)

Version Types

recommit Configuration

Basic Enterprise Roadmap

Name: Product Releases
Branches: main; release-2026-q1; release-2025-q4; v5-lts
Cherry-pick to Default Branch: Enabled

Separate Roadmaps by Urgency

Roadmap 1: All Supported Versions

Name: Standard Backports
Branches: main; release-2026-q1; release-2025-q4; v5-lts; v4-lts

Roadmap 2: LTS Only (Security)

Name: LTS Security
Branches: v5-lts; v4-lts; v3-lts

Use different roadmaps for different repositories or link manually based on fix urgency.

Real-World Example

Scenario: Enterprise CRM System

Your company sells a CRM to enterprise customers:

Your branches:

main (development)
release-2026-q1 (just released)
release-2025-q4 (most customers)
v5-lts (enterprise tier)
v4-lts (legacy enterprise)

Workflow: Critical Bug Fix

1. Report: Customer reports data export bug
2. Fix: Engineer fixes on main
3. Merge: PR merged to main
4. Auto Cherry-Pick: recommit creates PRs for:
   • release-2026-q1
   • release-2025-q4
   • v5-lts
   • v4-lts
5. Review: QA reviews each PR
6. Deploy: Release patches per branch
7. Notify: Inform affected customers

Managing Customer Expectations

Version Support Policy

Define clear policies:

## Version Support Policy
 
| Version | Status | Support Until |
|---------|--------|---------------|
| 2026-Q1 | Active | Q1 2027 |
| 2025-Q4 | Active | Q4 2026 |
| v5 LTS | Active | Dec 2028 |
| v4 LTS | Limited | Jun 2026 |
| v3 LTS | EOL | Dec 2025 |

Communicating Updates

When recommit backports a fix:

1. Merge the auto-created PRs
2. Generate release notes per version
3. Notify customers on their version
4. Update support documentation

Handling Quarterly Releases

New Release Branch

When starting a new quarter:

1. Create branch from main: release-2026-q2
2. Update roadmap to include new branch
3. Consider removing oldest supported version

End of Life

When retiring a version:

1. Announce EOL date to customers
2. Remove branch from roadmap
3. Final security patches only
4. Archive the branch

Integration with Enterprise Tooling

Jira Integration

Track backports in Jira:

• Original ticket links to main PR
• Child tickets for each version
• Auto-close when PRs merged

Release Management

Coordinate with your release process:

• Staging environments per version
• Automated testing per branch
• Deployment pipelines per customer

Best Practices for Enterprise

1. Document Everything

• Which customers use which versions
• Support timelines per version
• Backport policies

2. Test Each Version

Each backported PR should be:

• Reviewed by QA
• Tested in version-specific environment
• Validated against customer scenarios

3. Communicate Proactively

• Notify customers of available patches
• Provide clear upgrade paths
• Document known issues per version

4. Plan Upgrades

Help customers upgrade:

• Migration guides between versions
• Deprecation warnings
• Incentives for staying current

Compliance Considerations

Audit Trail

recommit provides:

• Complete history of all cherry-picks
• Links to original PRs and created PRs
• Timestamps for all actions

Change Control

Document that:

• recommit automates cherry-pick creation
• Humans still review and approve each PR
• Final merge is manual (auditable)

Time and Cost Savings

Before recommit

After recommit

Savings: ~22 hours/month = 264 hours/year

Related

• Library Versioning
• Security Patches
• Create Roadmap