Hotfix Process#

Overview#

Summary of the RAPIDS release process for hotfixes.

Intended audience#

Developers

Project Leads

Operations

See also#

Hotfixes#

Hotfix (or patch) releases are not preplanned and are made to address critical issues with the current release. The criteria and process below are set as a guideline to help determine what is a hotfix.

Criteria#

A hotfix is a significant bug that affects the majority of users for which there is no reasonable workaround.

So consider these questions:

  • Is this bug significant?

    • Does it produces incorrect results?

    • Are there compile or runtime errors with valid input?

    • Is there major incorrect functionality?

  • Does it affect the majority of users?

    • Does the bug affect a common or major function?

    • Is the input that causes the bug a common or edge case?

    • Will the average user encounter the bug during normal, average usage?

  • Is there a reasonable workaround?

    • Is there even a workaround?

    • Can a potential workaround be communicated effectively to the community?

    • Will the average user understand the workaround?

    • How many steps/code changes does a workaround take?

    • When the bug is fixed, does the workaround continue to work?

Also consider the timing of when the next release is scheduled. If the freeze or release date is within a few days, consider waiting and including the hotfix in the next release instead.

Process#

NOTE: The processes below use these releases as examples:

  • Current release YY.MA.PX

  • Next release YY.MB.0 (where MB=MA+2)

  • Next patch release MM.MA.PY (where PY=PX+1)

Developers

  1. Hotfix issues will be assigned to you

  2. Create hotfix/YY.MA.PX branch from ^vYY.MA.00 (commit BEFORE the tag)

  3. Implement the fix succinctly

  4. Change the minimal amount of code required

  5. Update related documentation and unit tests

  6. It is acceptable to implement a quick fix and open a new issue for a more in depth solution

  7. Once complete, create a pull request targeting the following

  8. hotfix/YY.MA.PX → release/YY.MA and notify Operations

  9. hotfix/YY.MA.PX → main and notify Operations 1. This can also be done as a cherry-pick from release/YY.MA -> main

  10. NOTE: After the release/YY.MA has completed, the forward merger will no longer automatically merge from release/YY.MA -> main

  11. Notify the project lead

Project Leads

  1. Identify potential hotfixes

  2. Ensure that the hotfix criteria is met

  3. Assign the issue and track its progress

  4. Notify Operations that a hotfix is being worked on

  5. Once notified that the pull request is created, review and approve it. Do NOT merge the pull request.

  6. Notify Operations that the hotfix pull request is ready for merging

Operations

  1. Once notified by a Project Lead, review the pull request

  2. Begin testing of conda and containers for correctness and functionality

  3. Review documentation to ensure version numbers (updating to YY.MA.PX) and instructions are correct

  4. Merge the developer’s PR from the hotfix/YY.MM.PX targeting release/YY.MA after approval

  5. Merge the developer’s PR from the hotfix/YY.MM.PX targeting main after approval

  6. Monitor process of automated tools

  7. Spot check deliverables to ensure correctness