Skip to contents

Release Strategy

Source: vignettes/release_strategy.Rmd
release_strategy.Rmd

Introduction

This article explains how we do package releases for admiral and across all our package extensions. This includes details around planned/scheduled releases, as well as hotfixes.

Release Schedule

A release schedule is maintained on the homepage.

Planning Releases

Whenever we start looking towards a future release, we create a new release issue label on GitHub of the form release Q4-2022 for example. This then can be added to all the issues we plan to cover in the release and these can be moved to the Priority column of our project board.

We should share in advance with our users a high level summary of expected package updates via the community meetings, especially any anticipated breaking changes.

Package Release Process

Quarterly Release

A package release is done in five parts:

  1. Create a Pull Request from devel into the pre-release branch. Issues identified in this Pull Request should have work done in separate branches and merged into the pre-release branch and NOT devel.
  2. Verify that all CI/CD checks are passing for the devel into the pre-release Pull Request, merge and then bundle up and send off to CRAN.
  3. Once the package is available on CRAN, another Pull Request is created for merging the pre-release branch into the main branch. This will trigger the GitHub action to rebuild the admiral website with all the updates for this release.
  4. Use the release button on GitHub to “release” the package onto GitHub. This release onto Github archives the version of code within the main branch, attaches the News/Changelog file, bundles the code into a tar.gz file and makes a validation report via the GitHub action validation from insightsengineering/validatoR. Please see past admiral releases for reference.
  5. Any issues fixed in the pre-release/main branches should be merged back into devel.
  6. Once a release is completed the main branch should be merged into patch to be ready for hotfixes.

Quarterly Release:

  • devel >> pre-release >> main
  • pre-release >> main >> devel (Fixes done after a CRAN rejection)
  • main >> patch (To be prepared in case of a needed hotfix)

Hot Fix Release

Occasionally we will need to release a hot fix to address a package breaking bug. A hot fix release is done in 6 parts:

  1. Identify all the bugs that need to be fixed for this hot fix release and label with hot fix label.
  2. Branches addressing the bugs should have Pull Requests merged into the patch branch NOT the devel branch.
  3. When naming the branch follow the naming conventions guide but use the @main suffix
  4. Create a Pull Request from patch into the pre-release branch. Verify that all CI/CD checks are passing, merge and bundle up and send off to CRAN.
  5. Once package is approved and available on CRAN, another Pull Request is created for merging the pre-release branch into the main branch. This will trigger the action to rebuild the admiral website with all the updates for this hot fix release.
  6. Use the release button on GitHub to “release” the package onto GitHub. This release onto Github archives the version of code within the main branch, attaches the News/Changelog file, bundles the code into a tar.gz file and makes a validation report via the GitHub action validation from insightsengineering/validatoR. Please see past admiral releases for reference.
  7. These hot fixes should then be merged into the devel branch through an additional Pull Request.

Hot Fix Release: patch >> pre-release >> main >> devel

Communications

After the release, we raise awareness via our Slack channel and LinkedIn.