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 four parts:

  1. Verify that all CI/CD checks and then bundle up and send off to CRAN. See the chapter in R Packages for more details.
  2. If CRAN asks for modifications, repeat steps 1-2 as necessary.
  3. Once the package is accepted and available on CRAN, a GitHub action is set up 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 and the Releasing to Github section for more details.

Quarterly Release:

  • main >> patch (To be prepared in case of a needed hotfix)

Hot Fix Release

Rarely, we may need to release a hot fix to immediately address a bug. In the majority of cases, an off-cycle release can be made directly from the main branch, where bug fixes and new features would be released earlier than planned, thus avoiding the patch branch release.

A hot fix release is done in eight 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 a single patch branch NOT the main branch, where the patch branch has been created from the most recent release of the package.
  3. When naming the branch follow the naming conventions guide.
  4. Create a Pull Request from patch into the main branch. Verify that all CI/CD checks are passing, merge and them bundle up and send off to CRAN. See the chapter in R Packages for more details.
  5. If CRAN asks for modifications, repeat steps 1-4 as necessary.
  6. Once the package is accepted and available on CRAN, a GitHub action is set up to rebuild the admiral website with all the updates for this release.
  7. Create a GitHub release on the patch branch. Please see past admiral releases for reference and the Releasing to Github section for more details.
  8. These hot fixes should then be merged into the main branch through an additional Pull Request. After the merge into the main branch, ensure the package version number is appropriately bumped to a development version.

Releasing to Github

Under the Releases section in the main repo, select Draft a New Release. Proceed by creating the appropriate release tag and header, denoted as vX.X.X and admiral X.X.X respectively, for the release:

Copy the contents of the NEWS.md section for the release, paste it into the release notes section:

Then in the upload box where it says, “Attach binaries by dropping them here or selecting them” upload the appropriate admiral_X.X.X.tar.gz file available for download at the CRAN website. Click Publish Release and you’re all done!

Communications

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