[Release]: <0.2.6> (End of October)

[shajoezhu]

Blocked by

• update logo #168

Issues

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 (certain PRs will be reviewed in the next increment).
• 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, and decide what gets merged in before starting release activities.

Release Process

We adopt the policy of one release branch containing all the fixes and changes deriving from internal validation feedback. This is done within the safety of having already green integration tests before release. No significant change is expected and we want a clean main.

• Create release branch as follows:

# Create a new branch to do the vbump for a given
# release candidate.
git checkout main
git pull origin main
git checkout -b release-candidate-vX.Y.Z

Make sure of the following before continuing:

• 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
• Make sure to change the package version to the release version (X.Y.Z) in DESCRIPTION and NEWS files.
• Update NEWS.md file: make sure it reflects a holistic summary of what has changed in the package, check merged PRs since last release.
• Check that README is updated and displays current information.
• 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.Y.Z
• 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 [These are the 
# 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

• tag the update(s) as a release candidate v-rc (e.g. v0.5.3-rc1) on the release (candidate) branch. Note that tags are created in GitHub and synchronized with GitLab automatically. You can do it with the following:

# 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>

• The package is submitted for internal validation by the Release Coordinator (Applicable only for regulatory release). Please use only the following format: https://github.com/insightsengineering/<pkg_name>.git@vX.Y.Z-rcX
• Address any feedback (internal validation/user testing), retag the package as a release candidate vX.Y.Z-rc(n+1). Fixes can be done on the release branch or on fix branches pointing to the release branch. If the fixes/changes are REALLY consistent, we suggest merging on main, open feature branches with fixes and recreate the release branch. 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.Y.Z on the main branch.
• Update downstream package dependencies to (>=x.y.z).

Testing

• Integration tests results - accepted (Internal Compute Environments/Validation Pipelines).
• 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 repositories).
• 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.

[Melkiades]

@shajoezhu can you please merge this document with insightsengineering/rtables#734 that has better clarifications about branching and tagging methods?