...
- Decide with team if a bug should be dropped back to previous release or not, consider things like (use fix-version field in Jira to indicate this)
- bug was reported by user of previous release (easy decision
)
- bug exposes behavior that was not in line with acceptance criteria for a user story that was delivered in previous release
- bug was reported by user of previous release (easy decision
- Make the fix and have it merged in master branch
- use minimal code to avoid merge/drop back issues
- specific test for bug fix should be included where possible
- Cherry pick the fix from master branch to release branch
- From Gerrit:
- Navigate to ... / Cherry Pick
- Fill the form with the release branch name (honolulu) in "Cherry Pick to branch" field and click "Cherry Pick"
- Using local branch (to resolve cherry-pick conflicts):
- Create local branch from honolulu
- Cherry-pick commit from master branch
- Resolve conflicts
- git push origin HEAD:refs/for/honolulu
- From Gerrit:
- Review patch by peers as normal
- Update Release version in a separate commit if required, seeand when required
A few bugs can be combined in one patch.
Release notes doc should be updated too
Typically only the 'patch' number (last digit) should be increased. See also- Release Versioning Strategy (proposal for Honolulu)
- ONAP API Common Versioning Strategy (CVS) Guidelines
- Once the fix is in release branch, deliver releases artifacts from release branch as described in previous section.
...