[x] Make sure that high priority bugs (label "priority" + "bug") have been resolved before going into the release.
[x] Review old/hanging PRs before going into the release.
[x] Revisit R-package's lifecycle badges (Optional).
~- [ ] Release Manager: Discuss package dependencies, create a plan to sequentially close release activities and submit groups of packages for internal validation (Applicable only for regulatory release).~
~- [ ] Check Validation Pipeline dry-run results for the package.~
~- [ ] Make sure all relevant integration tests are green 2-3 days before the release. Look carefully through logs (check for warnings and notes).~
[x] Inform about the soft code freeze, decide what gets merged in before starting release activities.
Release
Prepare the release
[x] Create a new release candidate branch
git checkout -b release-candidate-vX.Y.Z
[x] Update NEWS.md file: make sure it reflects a holistic summary of what has changed in the package, check README.
~- [ ] Remove the additional fields (Remotes) from the DESCRIPTION file where applicable.~
[x] Make sure that the minimum dependency versions are updated in the DESCRIPTION file for the package.
[x] Increase versioned dependency on {package name} to >=X.Y.Z.
[x] Commit your changes and create the PR on GitHub (add "[skip vbump]" in the PR title). Add all updates, commit, and push changes:
# Make the necessary modifications to your files
# Stage the changes
git add <files your modified>
# Commit the changes
git commit -m "[skip vbump] <Your commit message>"
git push origin release-candidate-vX.Y.Z
Test the release
~- [ ] Execute the manual tests on Shiny apps that are deployed on various hosting providers (Posit connect and shinyapps.io) - track the results in GitHub issue (Applicable only for frameworks that use Shiny).~
~- [ ] Monitor integration tests, if integration fails, create priority issues on the board.~
[x] Execute UAT tests (Optional).
Validation loop N/A
Note: This section is applicable only for regulatory packages.
~- [ ] Tag the update(s) as a release candidate vX.Y.Z-rc (e.g. v0.5.3-rc1) on the release candidate branch (release-candidate-vX.Y.Z).~
# Create rc tag for submission for internal validation
git tag vX.Y.Z-rc<iteration number>
git push origin vX.Y.Z-rc<iteration number>
~- [ ] Submit the package for internal validation.~
~- [ ] Address any feedback (internal validation/user testing), retag the package as a release candidate vX.Y.Z-rc(n+1). Repeat the submission for internal validation if necessary.~
~- [ ] Get the package validated.~
Tag the release
~- [ ] If the additional fields were removed, add them back in a separate PR, and then merge the PR back to main (add "[skip vbump]" in the PR title).~ If nothing was removed just merge the PR you created in the "Prepare the release" section to main. Note the commit hash of the merged commit. Note: additional commits might be added to the main branch by a bot or an automation - we do NOT want to tag this commit.
Make sure of the following before continuing with the release:
[x] CI checks are passing in GH.
~- [ ] Shiny apps are deployable and there are no errors/warnings (Applicable only for frameworks that use Shiny).~
[x] Create a git tag with the final version set to vX.Y.Z on the main branch. In order to do this:
Checkout the commit hash.
git checkout <commit hash>
Tag the hash with the release version (vX.Y.Z).
git tag vX.Y.Z
Push the tag to make the final release.
git push origin vX.Y.Z
[x] Update downstream package dependencies to (>=X.Y.Z) in {package name}.
Note: Once the release tag is created, the package is automatically published to internal repositories.
Post-release
[ ] Make sure that the package is published to internal repositories (Validated and/or Non-Validated repository).
[x] Review and update installation instructions for the package if needed.
[ ] Make sure internal documentation/~documentation catalogs~N/A are up to date.
[x] Notify the IDR team to start post-release/clean-up activities.
ddsjoberg
commented
4 months ago
Blocked by
PRs
Issues
Pre-release
Release
Prepare the release
git checkout -b release-candidate-vX.Y.ZRemotes) from the DESCRIPTION file where applicable.~Test the release
~- [ ] Execute the manual tests on Shiny apps that are deployed on various hosting providers (Posit connect and shinyapps.io) - track the results in GitHub issue (Applicable only for frameworks that use Shiny).~ ~- [ ] Monitor integration tests, if integration fails, create priority issues on the board.~
Validation loop N/A
Note: This section is applicable only for regulatory packages.
~- [ ] Tag the update(s) as a release candidate vX.Y.Z-rc (e.g. v0.5.3-rc1) on the release candidate branch (release-candidate-vX.Y.Z).~
~- [ ] Submit the package for internal validation.~ ~- [ ] Address any feedback (internal validation/user testing), retag the package as a release candidate vX.Y.Z-rc(n+1). Repeat the submission for internal validation if necessary.~ ~- [ ] Get the package validated.~
Tag the release
~- [ ] If the additional fields were removed, add them back in a separate PR, and then merge the PR back to main (add "[skip vbump]" in the PR title).~ If nothing was removed just merge the PR you created in the "Prepare the release" section to
main. Note the commit hash of the merged commit. Note: additional commits might be added to themainbranch by a bot or an automation - we do NOT want to tag this commit.Make sure of the following before continuing with the release:
[x] CI checks are passing in GH. ~- [ ] Shiny apps are deployable and there are no errors/warnings (Applicable only for frameworks that use Shiny).~
[x] Create a git tag with the final version set to vX.Y.Z on the main branch. In order to do this:
git checkout <commit hash>git tag vX.Y.Zgit push origin vX.Y.Z[x] Update downstream package dependencies to (>=X.Y.Z) in {package name}. Note: Once the release tag is created, the package is automatically published to internal repositories.
Post-release
Decision tree
Click here to see the release decision tree.