Hotfix Process
Hotfix Process
Overview
Summary of the RAPIDS release process for hotfixes.
Intended audience
Developers {: .label .label-green}
Project Leads {: .label .label-blue}
Operations {: .label .label-purple}
See also
- [Hotfix versioning]({% link resources/versions.md %})
- [Major and minor releases]({% link releases/process.md %})
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
M.A.X
- Next minor release
M.B.0
(whereB=A+1
) - Next patch release
M.A.Y
(whereY=X+1
)
Developers {: .label .label-green}
- Hotfix issues will be assigned to you
- Create your branch from the
branch-M.A
branch - Implement the fix succinctly
- Change the minimal amount of code required
- Update related documentation and unit tests
- It is acceptable to implement a quick fix and open a new issue for a more in depth solution
- Once complete, create a pull request targeting
branch-M.A
- Notify the project lead
Project Leads {: .label .label-blue}
- During [triage]({% link releases/triage.md %}), identify potential hotfixes
- Ensure that the hotfix criteria is met
- Assign the issue and track its progress
- Notify Operations that a hotfix is being worked on
- Once notified that the pull request is created, review and approve it. Do NOT merge the pull request.
- Notify Operations that the hotfix pull request is ready for merging
Operations {: .label .label-purple}
- Once notified by a Project Lead, review the pull request
- Begin testing of conda and containers for correctness and functionality
- Review documentation to ensure version numbers (updating to
M.A.Y
) and instructions are correct - Merge the developer’s PR targeting
branch-M.A
after approval - Create a new PR from
branch-M.A
targetingmain
- Merge the PR targeting
main
after review and approval - Monitor process of automated tools
- Spot check deliverables to ensure correctness