Versions Compared

Old Version 65

changes.mady.by.user Toine Siebelink

Saved on

compared with

New Version 66

changes.mady.by.user Toine Siebelink

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. 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)
    1. bug was reported by user of previous release (easy decision (smile))
    2. bug exposes behavior that was not in line with acceptance criteria for a user story that was delivered in previous release
  2. Make the fix and have it merged in master branch
    1. use minimal code to avoid merge/drop back issues
    2. specific test for bug fix should be included where possible
  3. Cherry pick the fix from master branch to release branch
    1. From Gerrit:
      1. Navigate to ... / Cherry Pick
      2. Fill the form with the release branch name (honolulu) in "Cherry Pick to branch" field and click "Cherry Pick"


    2. Using local branch (to resolve cherry-pick conflicts):
      1. Create local branch from honolulu  (create branch & switch to branch)
      2. Cherry-pick commit from master branch
      3. Resolve conflicts
      4. Continue cherry-pick (git cherry-pick --continue)
      5. git push origin HEAD:refs/for/honolulu (or git review)
  4. Review patch by peers as normal
    1. Ensure that Gerrit merge requests both in master and release branches have the same Change-Id value (ex: https://gerrit.onap.org/r/q/Ia58a8dfcf427e373b24bb3be7436abf6abd55492). Then, related fixes can be easily filtered and clicking on the Change-Id from one change provides the list of all related ones.
  5. Update Release version in a separate commit if and 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
    1. Release Versioning Strategy (proposal for Honolulu)
    2. ONAP API Common Versioning Strategy (CVS) Guidelines
  6. Once the fix is in release branch, deliver releases artifacts from release branch as described in previous section.

Preparing for third party (stakeholder) testing of specific features  before general (onap) release

  1. Ensure a Jira is created and shared with stakeholder to track the required change
    1. CPS Team might create dependent (blocking) Jira's link to the main Jira as required
  2. Common Acceptance criteria:
    1. latest RTD Design docs get update with relevant APIs (e.g. https://docs.onap.org/projects/onap-cps/en/latest/design.html)
    2. latest RTD Release Note (new snapshot section) wil be updated with the delivered Jira (from step 1)  (similar to https://docs.onap.org/projects/onap-cps/en/latest/release-notes.html#version-2-0-1)
    3. CSIT test wil be updated/added to cover new functionality
    4. Demo to stakeholder (this is realy the best sign it is -almost-  done to the stakeholder)
  3. Jira can be closed (stakeholder can subscribe to notifications about this)

References