Release Strategy

This document outlines the comprehensive release strategy for the Dev Box landing zone accelerator, detailing branch-based versioning, automated workflows, and deployment processes.

Overview

The Dev Box landing zone accelerator uses a branch-based semantic release strategy with intelligent overflow handling and conditional versioning rules. This approach ensures consistent, predictable releases while maintaining development flexibility across different branch types.

Build and Deploy Status

Deploy to Azure Release

Releases

Learn more about the Dev Box accelerator landing zone releases.

Release Strategy Summary

Branch PatternVersion StrategyRelease PublicationTag CreationArtifacts
mainConditional major incrementβœ… Publishedβœ… Createdβœ… Built & Uploaded
feature/**Patch increment with overflow❌ Not publishedβœ… Createdβœ… Built & Uploaded
fix/**Minor increment with overflow❌ Not publishedβœ… Createdβœ… Built & Uploaded
pull_requestBased on source branch❌ Not publishedβœ… Createdβœ… Built & Uploaded

Branch-Specific Versioning Rules

🎯 Main Branch (main)

New Conditional Major Increment Rule:

  • If minor = 0 AND patch = 0: Increment major version
    • Example: v1.0.0 β†’ v2.0.0
  • If minor β‰  0 OR patch β‰  0: Keep major version, increment patch
    • Example: v1.5.0 β†’ v1.5.1
    • Example: v1.0.3 β†’ v1.0.4
    • Example: v1.5.3 β†’ v1.5.4

Overflow Handling:

  • If patch exceeds 99: Reset patch to 0, increment minor
    • Example: v1.5.99 β†’ v1.6.0
  • If minor exceeds 99: Reset minor to 0, increment major
    • Example: v1.99.99 β†’ v2.0.0

✨ Feature Branches (feature/**)

Patch Increment Strategy:

  • Increments the patch version by the number of commits in the branch
  • Format: vX.Y.(Z+commits)-feature.branch-name

Examples:

  • Current: v1.2.5, Branch: feature/user-authentication, Commits: 3
  • Result: v1.2.8-feature.user-authentication

Overflow Logic:

  • If patch + commits > 99: Reset patch to 0, increment minor
  • If minor overflow occurs: Reset minor to 0, increment major

πŸ”§ Fix Branches (fix/**)

Minor Increment Strategy:

  • Increments the minor version by the number of commits in the branch
  • Format: vX.(Y+commits).Z-fix.branch-name

Examples:

  • Current: v1.2.5, Branch: fix/login-bug, Commits: 2
  • Result: v1.4.5-fix.login-bug

Overflow Logic:

  • If minor + commits > 99: Reset minor to 0, increment major

Version Examples

Main Branch Scenarios

Current VersionConditionActionResultReasoning
v1.0.0minor=0, patch=0Major incrementv2.0.0Clean state allows major bump
v1.5.0minor≠0, patch=0Patch incrementv1.5.1Development continues on current major
v1.0.3minor=0, patch≠0Patch incrementv1.0.4Development continues on current major
v1.5.99Patch overflowMinor incrementv1.6.0Patch overflow triggers minor bump
v1.99.99Cascading overflowMajor incrementv2.0.0Full overflow resets to new major

Feature Branch Scenarios

Current VersionBranchCommitsCalculationResult
v1.2.5feature/auth35 + 3 = 8v1.2.8-feature.auth
v1.2.97feature/ui597 + 5 = 102 > 99v1.3.0-feature.ui
v1.99.95feature/api8Cascading overflowv2.0.0-feature.api

Fix Branch Scenarios

Current VersionBranchCommitsCalculationResult
v1.5.3fix/bug-12325 + 2 = 7v1.7.3-fix.bug-123
v1.98.3fix/critical398 + 3 = 101 > 99v2.0.3-fix.critical

Release Notes Structure

Each release includes comprehensive documentation:

🌟 **Branch-Based Release Strategy with Conditional Major Increment**

πŸ”€ **Branch**: `main`
🏷️ **Version**: `v2.0.0`
πŸ“¦ **Previous Version**: `v1.0.0`
πŸš€ **Release Type**: `main`
πŸ€– **Trigger**: `Push`
πŸ“ **Commit**: `abc123...`

## Release Strategy Applied
🎯 **Main Branch**: Conditional major increment (only if minor=0 AND patch=0)

## Main Branch Logic
- **If minor=0 AND patch=0**: Increment major β†’ `major+1.0.0`
- **If minor≠0 OR patch≠0**: Keep major, increment patch → `major.minor.(patch+1)`
- **Overflow handling**: If patch > 99 β†’ `minor+1, patch=0`

## Artifacts
- πŸ“„ Bicep templates compiled to ARM templates
- πŸ—οΈ Infrastructure deployment files
- πŸ“‹ Release metadata and documentation

Best Practices

For Developers

  1. Branch Naming: Use descriptive branch names following the patterns:

    • feature/descriptive-name
    • fix/issue-description
  2. Commit Strategy: Keep commits atomic and meaningful as they influence version calculations

  3. Testing: Ensure all changes are tested before merging to main

For Release Management

  1. Main Branch Protection: Only merge tested, reviewed code to main
  2. Version Monitoring: Monitor version progression to prevent unexpected major increments
  3. Release Planning: Use the conditional major increment rule for planned major releases
Last modified July 15, 2025: Release list (40c992d)