Git Versioning, Tagging & Release Schedule for Ashlar

Context

With the adoption of Docusaurus as our component library tool, release notes were moved from the Brand website on Drupal into Ashlar itself, so that the changelog lives with the component library documentation.

This created a minor challenge for our existing git workflow, because now updates to the changelog are git commits. When they were separate, it wasn't a very big deal if the documentation of changes happened before, at the same time, or after branches were merged and tagged.

Now, however, we want the commits logging the changes to be in sync with the tagged releases in git so that updates to the changelog aren't accidentally trailing the latest tagged release and creating messy git logs. This requires a minor adjustment in how we manage git branches on a weekly basis. This ADR outlines the most recent workflow.

Decision

As a reminder, we follow semantic versioning with this pattern:

release versioning with decimals 1.4.3, with the numbers between the decimals representing a release version. In this example, 1 represents a major release, 4 a minor, and 3 a patch

 

  • In general, will have one running patch release branch a week. This branch can be deployed throughout the week, as individual branches/pull requests are merged, so bugs are fixed quickly on prod sites
  • There may or may not also be a minor or major release branch alongside the patch branch. This branch receives changes to be deployed on the regular Monday schedule, or on some other pre-scheduled release date
  • On Mondays or the first workday of the week:
    1. Changes get documented for the changelog
    2. All outstanding branches/pull requests that are ready for release are merged into the appropriate release branch
    3. All release branches are merged into the main branch
    4. The main branch merge commits are tagged with the release version
    5. The main branch is synced between Bitbucket and GitHub (pushing main to GitHub will update the public-facing documentation and changelog)
    6. The new patch release branch is created from main, and is deployed to the latest production platform

The main shift from the old way of doing things is that now, main as the source of truth for things like the Drupal profile, with version tagging. It is no longer assumed to be the branch deployed to the production Drupal platform, instead it can be assumed that the latest patch release branch has been deployed.

Status

Accepted

Topics

Ashlar
Drupal
Procedure
Web Development