Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

[Release]: 0.1.19 #264

Closed
10 of 30 tasks
donyunardi opened this issue Feb 6, 2025 · 0 comments · Fixed by #265
Closed
10 of 30 tasks

[Release]: 0.1.19 #264

donyunardi opened this issue Feb 6, 2025 · 0 comments · Fixed by #265
Assignees
Labels
core release Pertaining to a software release

Comments

@donyunardi
Copy link
Contributor

donyunardi commented Feb 6, 2025

Pre-release

  • 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).
  • 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).
  • Inform about the soft code freeze, decide what gets merged in before starting release activities.

Release

Prepare the release

  • Create a new release candidate branch
    git checkout -b release-candidate-vX.Y.Z
  • 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.
  • 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
    # 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.
  • Execute UAT tests (Optional).

Validation loop

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:
  • CI checks are passing in GH.
  • Shiny apps are deployable and there are no errors/warnings (Applicable only for frameworks that use Shiny).
  • Create a git tag with the final version set to vX.Y.Z on the main branch. In order to do this:
    1. Checkout the commit hash.
      git checkout <commit hash>
    2. Tag the hash with the release version (vX.Y.Z).
      git tag vX.Y.Z
    3. Push the tag to make the final release.
      git push origin vX.Y.Z
  • 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).
  • Review and update installation instructions for the package if needed.
  • 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 24 FEB 2025.

Decision tree

Click here to see the release decision tree.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
core release Pertaining to a software release
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants