Skip to main content

Releases

Lorem ipsum...

Semantic Versioning​

Semantic Versioning, commonly known as “SemVer,” is a standardized versioning system that helps developers manage and communicate changes in software modules. In Terraform, Semantic Versioning is essential for managing module versions effectively, ensuring stability, and minimizing the risk of breaking changes when working with infrastructure as code. Using SemVer principles allows teams to confidently integrate new module versions, knowing the nature of changes (whether they are minor, patch, or major updates) and their potential impact on the infrastructure.

Terraform modules follow the SemVer format of MAJOR.MINOR.PATCH (e.g., 1.2.3), where each component of the version number indicates the type of changes made in the module:

  1. MAJOR (Breaking Changes): Incremented when there are incompatible API changes that may break backward compatibility, such as changing or removing variables, outputs, or resources.
  2. MINOR (New Features): Incremented when new, backward-compatible functionality is added to the module. Minor updates add functionality in a non-disruptive way.
  3. PATCH (Bug Fixes): Incremented for backward-compatible bug fixes. These updates address issues or add minor improvements without affecting existing functionality.

By adhering to Semantic Versioning, Terraform module developers can communicate the scope of changes more clearly, helping users and automation systems to determine when it is safe to upgrade. Tools like Terraform Registry and $ terraform init -upgrade commands leverage SemVer conventions to identify which versions can be safely updated, streamlining module management and version control.

Git Branches​

Git Flow

Git Flow is a branching model that organizes work into distinct branches for features, releases, and hotfixes, providing clear stages of development and release management. The main branches in this strategy are:

  1. main: Holds the production-ready code and reflects the latest stable release.
  2. develop: Serves as the integration branch where features are merged for testing and preparation before the next release. It should always be deployable but may include features under active testing.

Branch Types and Workflow​

1. Feature Branches (feature/*)​

  • Used for developing new features and enhancements.
  • Branch off from develop.
  • Merged back into develop after completion and review.
  • Naming convention: feature/feature-name.
git checkout develop
git checkout -b feature/feature-name

2. Release Branches (release/*)​

  • Created when preparing for a new version release.
  • Branch off from develop and named based on the upcoming major.minor version, e.g., release/1.0.
  • Serve as a staging area for testing and finalization. Only necessary changes and bug fixes should be applied here.
  • Once finalized, merged into both main and develop.
  • A version tag is created on main to mark the release.
git checkout develop
git checkout -b release/1.0  # For releasing version 1.0

3. Hotfix Branches (hotfix/*)​

  • Used for urgent fixes to the production version.
  • Branch off from main, and merged into both main and develop after completion.
  • Naming convention: hotfix/issue-name.
git checkout main
git checkout -b hotfix/fix-issue

4. Versioned Release Branches for Backporting (release/major.minor)​

  • For each major.minor release, a dedicated release branch is created, allowing for backporting of critical updates or specific features if needed.
  • These branches are named release/major.minor, such as release/1.0 for the 1.0 release series.
  • If a feature or fix needs to be backported, it can be cherry-picked or merged into the respective release/major.minor branch.
  • Changes made here can be merged into the corresponding release and tagged accordingly.
git checkout -b release/1.0  # Creates the release branch for version 1.0

Workflow Example for a New Release​

1. Developing New Features​

  • Start feature development by branching from develop into feature/feature-name.
  • Complete the feature, test, and merge it back into develop.

2. Preparing a Release​

  • When preparing for a versioned release (e.g., 1.0), create a branch from develop named release/1.0.
  • Finalize testing and make any last-minute fixes directly in this branch.
  • When ready, merge release/1.0 into both main (for production) and develop (to sync with the latest).

3. Version Tagging​

  • Tag the release on the main branch with the version number (e.g., v1.0.0).
git checkout main
git tag -a v1.0.0 -m "Release version 1.0.0"
git push origin v1.0.0

4. Backporting to Release Branches​

  • If a feature or fix needs to be backported to a previous release, use the relevant release branch (e.g., release/1.0).
  • Apply the change, test, and tag the updated release as necessary (e.g., v1.0.1).
┌── main      # latest version
├── release   # released versions
│   ├── 1.0
│   ├── 2.0
│   └── 3.0
├── feature   # development of branches
│   ├── bucket_acl
│   ├── bucket_cors
│   └── bucket_versioning
└── hotfix    # hotfixes
    └── aws_s3_bucket_prefix_name