[Release]: <0.9.1> (end of September)

[shajoezhu]

Blocked by

PRs

• Fix trailing "." when using format_sigfig, add functionality for multiple values #1067
• Refactor tabulate_rsp_subgroups to pass sanitation checks #1056
• Close #1026: Expose gpar to control graphic settings in g_forest. #1057
• Change to poisson dist to see if it is the glm fit to be unstable #1059
• Add "Patients at Risk" title for g_km at risk annotation table #1065

Issues

• Fix bug in format_sigfig causing trailing "." #1066
• Add "Patients at Risk" table label option to g_km #1064
• Investigate variable printout forsummarize_glm_count #1058 (decision: to mute it, to be updated in the Docker image)
• [Bug]: forest plot is too wide to save to a4 paper #1026
• Refactor tabulate_rsp_subgroups to pass sanitation check #1038

Pre-requisites

• Make sure that high priority bugs (label "priority" + "bug") have been resolved before going into the release.
• Review old/hanging PRs before going into the release.
• Revisit R-package's lifecycle badges (Optional). Not applicable
• Discuss package dependencies before going into release activities.
• 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).
• Check if a package is installable on our supported internal systems (Optional). Not applicable
• Inform about the soft code freeze, decide what gets merged in before starting release activities.

Release Checklist

• Recurring tasks: 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). Not applicable
• Recurring tasks: Monitor integration tests, if integration fails, create priority issues on the board.
• Make sure that CI checks are passing in GH before releasing the package.
• Sanity checks for Shiny applications e.g. checking if Shiny apps are deployable and making sure there are no errors/warnings. Not applicable
• 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 and Config/Needs/*) from the DESCRIPTION file where applicable. Not applicable
• Make sure that the minimum dependency versions are updated in the DESCRIPTION file for the package.
• Increase versioned dependency on {package name} to >=X.X.X.
• Create a pull request to make necessary bug fixes/changes (add "[skip vbump]" in the PR title), and after merging the PR, tag the update(s) as a release candidate v < intended release version > -rc < release candidate iteration > on the main branch. Note that tags are created in GitHub and synchronized with GitLab automatically.
• The package is submitted for internal validation by Release Coordinator (Applicable only for regulatory release).
• Address any feedback (internal validation/user testing), retag the package as a release candidate vX.X.X-rc(n+1). Repeat the submission for internal validation if necessary.
• Get the package validated (Applicable only for regulatory 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). Not applicable
• Create a git tag with the final version set to X.X.X on the main branch.
• Update downstream package dependencies to (>=X.X.X) in {package name}.

Testing

• Integration tests results - accepted.
• UAT results - accepted.
• Shiny apps test results - accepted (Applicable only for Shiny apps). Not applicable
• Necessary testing on target environment - performed (up to ETL).

Release Feedback

• Fix 1
• Enhancement 1
• Defect 1

Post-release Checklist

• Make sure that the package is published to internal repositories (Validated and/or Non-Validated repository).
• Review and update installation instructions for the package if needed.
• Verify if a new dev version (.9XXX) has been added to the NEWS.md file and DESCRIPTION file as a placeholder for release notes by automation.
• Make sure internal documentation/documentation catalogs are up to date.
• Notify the IDR team to start post-release/clean-up activities.
• Announce the release on ________.

Decision tree

Click here to see the release decision tree.