Skip to content

Scrumlr Release Process Guideline

Jump to bottom
Johann Böhler edited this page Nov 29, 2023 · 2 revisions

Scrumlr Release Process Guide

This guide outlines the steps and best practices involved in rolling out a new version of the Scrumlr web application. Following these steps will ensure a smooth and reliable release.

Prerequisites

  • Administrative privileges in the Scrumlr GitHub repository.
  • Familiarity with Semantic Versioning.
  • A completed and successful build on the main branch.

Overview

At Scrumlr, we embrace a flexible release approach:

  • Patches: Issued as needed to address critical bugs and security vulnerabilities.
  • Minor Releases: Bundled with new features and enhancements that do not introduce breaking changes.
  • Major Releases: Released when significant changes are made, which include breaking changes and require caution during the upgrade.

Scrumlr's release process does not adhere to a fixed schedule. Instead, releases are determined by the completion of significant features, the accumulation of sufficient minor changes, or the urgency of patches.

Steps

Step 1: Validate Main Branch Health
Ensure that GitHub Actions or any other CI/CD pipelines have completed successfully for the most recent commit to the main branch. Manual testing in the development environment is also recommended to verify that the main branch is stable and ready for release.

Step 2: Version Increment
Based on the changes, decide whether it's a major, minor, or patch release. Increment the version field accordingly in the package.json file and commit the change with the message format: Bump version to <new-version>. For example, if you are updating to version 1.2.3, your commit message should be Bump version to 1.2.3.

Step 3: Drafting the Release
Navigate to the repository's Releases page and click on Draft a new release.

Step 4: Tagging
For the tag version, prepend a 'v' to the new version number (e.g., v1.2.3).

Step 5: Release Description
Write a detailed release description that encapsulates all significant changes. Structure the updates into categories for clarity:

  • New Features: Introductions and enhancements that add new functionality.
  • Enhancements: Improvements to existing features.
  • Bug Fixes: Resolutions to known issues from previous versions.

Do not include changes that have no direct impact on the end user, such as internal dependency updates and modifications to tests or the build system.

Step 6: Final Checks
Before publishing, confirm that you have checked the Set as the latest release option. This will tag the new release as the most current version in the repository.

Step 7: Publish the Release
Review all the information for accuracy and completeness. Once verified, click on the Publish release button to make the release live. The images will be built automatically by our CI/CD pipeline upon publish.

Clone this wiki locally