Versions Compared

Key

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

...

  • (Fixed) Developers should do the following when fixing issues:
    1. All commits to subversion must include the corresponding JIRA number as the first word in the commit message. For example: svn commit -m "SAK-1234 fixed the uncaught NPE"
    2. If you are implementing a Feature Request or Contributed Patch, first use Move to covert the issue type to a Task
    3. If working in a branch, first merge your branch to trunk before resolving the issue
    4. Update Fix Version to the next major release version, do not use alpha or beta releases (e.g. use 2.8.2, 2.9, 2.10 : do NOT use 2.9b07, 2.9a1, trunk)
    5. Add a Test Plan under "Testing"
    6. Add relevant "Release Notes"
    7. Check the boxes, if appropriate, for Property addition/change required and/or Conversion Script Required
    8. Selects Merge for previous supported and affected releases (e.g. 2.8 Status) for bugs only (features are NOT merged back)
  • (Reopened) If QA reopens an issue:
    1. QA sets the Affects Version to the version tested
    2. In the process of verifying the issue, if you discover a different problem, create a new issue to capture it, rather than re-opening the current issue and re-using it; reserve re-opening only if the original problem is still present.
    3. Some issues can not be easily verified and may require special testing conditions or input from developers.
  • (Duplicate) If it duplicates a previous issue, then the newly opened issue is:
    1. Linked to the original issue as "duplicates"
    2. Commented with a note to look at the linked-to issue to track further progress
    3. Closed with a Resolution of "Duplicate"
    4. Fix Version and should be set to "Unknown"
  • (Incorporated) If it is incorporated into a previous issue, then the newly opened issue is:
    1. Linked to the original issue as "incorporated by"
    2. Commented with a note to look at the linked-to issue to track further progress
    3. Closed with a Resolution of "Incorporated"
    4. Fix Version and should be set to "Unknown"
  • (Non-Issue) If it turns out that the issue was the result of a mis-understanding of how Sakai operates, then:
    1. An effort is made to clarify the situation.
    2. If the mis-understanding does not suggest a design flaw, then it is Closed with a Resolution of "Non-issue"; otherwise, the design flaw could be captured to Bug or Feature Request.
    3. Fix Version should be set to "Unknown"
  • (Incomplete) If insufficient information is provided to describe the issue, then:
    1. A comment is added to ask the user to include the needed information (should list the information needed)
    2. The issue is closed with a Resolution of "Incomplete"; issue can always be Reopened.
    3. Fix Version should be set to "Unknown"
  • (Cannot Reproduce) If the issue cannot be reproduced on one of the QA test servers, then:
    1. A comment is entered to indicate what was attempted to reproduce the issue (e.g. "followed steps in issue")
    2. The issue is closed with a Resolution of "Cannot Reproduce"; issue can always be Reopened.
    3. Fix Version should be set to "Unknown"

...

  • Alpha, Beta, and RC tags (e.g., alpha03, beta02, RC01) - After a release is made, the interim alpha, beta, and release candidate versions are merged into the released version. For example, 2.6.0-alpha01, 2.6.0-alpha02, 2.6.0-beta01, 2.6.0-rc01, etc. would be merged into 2.6.0. The merging is necessary for keeping it simple to search, filter, and view issues for released versions of Sakai; however, the original version numbers are still associated with each issue in the database, if there is a need to extract such information later on.
  • Maintenance Branch versions as Affects Versions (e.g., 2.3.x, 2.4.x)  You should generally avoid using maintenance branch version as an Affects Version, unless you are sure an issue does not affect past releases on that branch. This is important because branch versions are moving targets; what affects 2.5.x one day will not necessarily affect it in the future, after the issue is fixed.
  • Maintenance Branch versions as Fix Versions (e.g., 2.3.x, 2.4.x) - Generally the only branch version a developer needs to be concerned with is the next major release version for changes they are checking in to trunk. Only the Branch Managers should worry about using maintenance branch versions or beta versions as Fix Versions. They will use maintenance branch versions only when the fix is actually checked-in to the branch. It should not be used as an indication that one would like a fix merged (rather one should set the maintenance branch's status to "Merge".)
  • SAK Experimental Branches (i.e., branch) - Use the generic "branch" version as the Fix Version when working on subtasks under a SAK Experimental Branch. If and when the branch is merged into trunk, please remember to update the Fix Version appropriately (generally this will mean changing it to the next major release at the time the branch is merged to trunk.)
  • Developers - only use actual release versions as the Fix Version and indicate it should be merged using the special "Merge" fields (as discussed in the CLE team).
  • Branch Managers - can use any version which is appropriate including beta or alpha versions (which are indicators of when something was merged and what it was merged into).

Maintenance Branch Version Numbers

...