Skip to content

Release 1.6 Checklist #8874

Description

@ericspod

This issue is to collect other issues and PRs that should be closed/merged for the upcoming 1.6. We first need to finalise the last PRs for the release. The we create a 1.6.0 branch, create release candidates through tagging, verify these work with tutorials/zoo/etc. and are present in PyPI.

Important PRs:

Important issues/Advisories:

Nice-to-have PRs/Issues

Checklist

Release a candidate version

  • Tag and release PYPI version [X.Y.Z]rc[K] following the contributing guide, need trigger release pipeline on blossom.
  • Make sure all CI pipelines pass.

Verify the new PyPI release

Quality assurance for the relevant repos

The new PyPI release candidate should be checked against all the relevant repositories under Project-MONAI, for example, the tutorials repo:

  • Run all Jupyter notebooks, replace pip install monai with pip install monai==[X.Y.Z]rc[K].
  • File new tickets and create new pull requests to address any technical issues.
  • Release a new candidate after addressing all the issues.
  • Testing related repositories
    • MONAI unit and integration tests
    • MONAI tutorial tests
    • MONAILabel unit and integration tests
    • MONAI model zoo tests
    • QA regression tests

Prepare documentation

Release a milestone version

Activity

  1. pinned this issue on May 30, 2026
  2. added theissue type on Jun 1, 2026
  3. added a commit that references this issue on Jun 8, 2026
  4. ericspod commented on Jun 11, 2026

    @ericspod
    MemberAuthor

    Contributing guide on publishing a release:

    Release a new version

    The dev branch's HEAD always corresponds to MONAI Docker image's latest tag: projectmonai/monai:latest. (No
    release is currently done for the slim MONAI image, this is built locally by users.)
    The main branch's HEAD always corresponds to the latest MONAI milestone release.

    When major features are ready for a milestone, to prepare for a new release:

    • Prepare a release note and release checklist.
    • Check out or cherry-pick a new branch releasing/[version number] locally from the dev branch and push to the codebase.
    • Create a release candidate tag, for example, git tag -a 0.1.0rc1 -m "release candidate 1 of version 0.1.0".
    • Push the tag to the codebase, for example, git push origin 0.1.0rc1.
      This step will trigger package building and testing.
      The resultant packages are automatically uploaded to
      TestPyPI. The packages are also available for downloading as
      repository's artifacts (e.g. the file at https://github.com/Project-MONAI/MONAI/actions/runs/66570977).
    • Check the release test at TestPyPI, download the artifacts when the CI finishes.
    • Optionally run the cron testing jobs on releasing/[version number].
    • Rebase releasing/[version number] to main, make sure all the test pipelines succeed.
    • Once the release candidate is verified, tag and push a milestone, for example, git push origin 0.1.0.
      The tag must be with the latest commit of releasing/[version number].
    • Upload the packages to PyPI.
      This could be done manually by twine upload dist/*, given the artifacts are unzipped to the folder dist/.
    • Merge releasing/[version number] to dev, this step must make sure that the tagging commit unchanged on dev.
    • Publish the release note.

    Note that the release should be tagged with a PEP440 compliant version number.

    If any error occurs during the release process, first check out a new hotfix branch from the releasing/[version number],
    then make PRs to the releasing/[version number] to fix the bugs via the regular contribution procedure.

    If any error occurs after the release process, first check out a new hotfix branch from the main branch,
    make a patch version release following the semantic versioning, for example, releasing/0.1.1.
    Make sure the releasing/0.1.1 is merged back into both dev and main and all the test pipelines succeed.

  5. mingxin-zheng commented on Jun 19, 2026

    @mingxin-zheng
    Collaborator

    For the GHSA-qxq5-qhx6-94qw, if a user explicitly sets MONAI_ALLOW_PICKLE=1 and loads an untrusted .pkl, it's still exploitable. But the default-on attack surface is gone, which is what matters for the CVE. Will we request a correction to GHSA-89gg-p5r5-q6r4 (patched version should be 1.6.0, affected range < 1.6.0)?

  6. ericspod commented on Jun 19, 2026

    @ericspod
    MemberAuthor

    For the GHSA-qxq5-qhx6-94qw, if a user explicitly sets MONAI_ALLOW_PICKLE=1 and loads an untrusted .pkl, it's still exploitable. But the default-on attack surface is gone, which is what matters for the CVE. Will we request a correction to GHSA-89gg-p5r5-q6r4 (patched version should be 1.6.0, affected range < 1.6.0)?

    Could you please request an improvement here and change the versions affected and patched as suggested? I don't know how the review process for this goes, ie. if it comes to me to review or what. Thanks!

  7. ericspod commented on Jun 23, 2026

    @ericspod
    MemberAuthor

    The Dockerhub build also needs to be done manually, this was disabled with #7450 owing to resource constraints, combined with Blossom no longer being used.

  8. mingxin-zheng commented on Jun 26, 2026

    @mingxin-zheng
    Collaborator
  9. unpinned this issue on Sep 17, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

No labels
No labels

Type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions