Versions Compared

Key

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

...

Issue Type

Definition for Sakai

Bug

An error in design or implementation which directly impedes a user from achieving their expected result.

Task

A new capability being added to Sakai.

Feature Request

A desired capability, which may be selected for implementation in a future release of Sakai.

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="9ca76909976d6b08-2362f526-48574b10-8cf49c91-e85239c43c79cc88c0c6812d"><ac:plain-text-body><![CDATA[

Contributed Patch

A community-contributed patch to a particular version of sakai. The origin of such issues may lie in Bugs or Feature Requests which Sakai has not yet evaluated for implementation. Under such circumstances a linked issue is generally created by cloning the orignal issue in order to track Sakai's work on the issue. [Use at your own risk!]

]]></ac:plain-text-body></ac:structured-macro>

...

Both of these versions, however, are not necessarily meaningful for all issue types. The table below summarizes how they are used for each in the context of specific issue typetypes.

Issue Type

Affects Version

Fix Version

Bug

Version in which bug was identified.

Version in which bug is expected to be or has actually been resolved. (star)

Task

Not required, but may provide useful context for comments on the issue.

Version in which new capabilitity is expected to appear or has appeared. (star)

Feature Request

Not required, but may provide useful context for comments on the issue.

Not applicable. (Note that Feature Requests selected for implementation are currently converted to one or more Tasks for tracking the actual work.)

Contributed Patch

Version to which the patch can be applied.

Not applicable. (Note that Contributed Patches are cloned to provide a separate Bug or Feature Request for tracking Sakai work on the issue.)

(star) For both Bug and Task issues the fix version is set fix version depending depends on whether the issues is unresolved ("expected" fix version) or resolved ("actual" fix version). For unresolved issues, which are still being worked on, the fix version is set to the "whole" release number (e.g., 2.1.0, 2.1.1, 2.2.0) in which the issue is expected to be resolved. For resolved issues, the fix version is initially set to the actual interim QA release number (e.g., 2.1.0.001, 2.1.0.002) in which the issue was resolved. After ; after a release is made, the interim QA release versions are merged into a single release the last QA version number for clarity, (i.e., 2.1.0.001, 2.1.0.002, 2.1.0.003, were merged into 2.1.0. are merged into 006).

Further notes on Version Numbers

When development work predominates on a branch – prior to a the branch entering QA – the version number to report issues against is basically a moving target. In other words, as fixes are checked into a branch, there is currently no change in the version used to refer to that branch; the SVN revision number, however, does change, so use that if you need to track that level of granuliarty. For instance, for issues encountered on the trunk branch, report the Affects Version as "Nightly/SVN-Trunk"; for issues encoutered on a production/maintenance branch that is not yet in QA, report the Affects Version as <version>.000 (e.g., 2.1.0.000, 2.1.1.000). When such issues are resolved prior to QA, the Fix Version is similar set, which helps identify potentially transient issues that might not need full attention during QA.

Anchor
Priority
Priority
Priority

...