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/Requirement

A desired capability, for inclusion in a future release of Sakai; ideas that come with resources interested in implementing them are more likely to be developed than those offered with the hope that someone else will step forward to do the work.

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="9a553d982c863d29-3c92a56d-40014f66-b6579bfb-433ec3d88ece31d42d8ffb6b"><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>

...

Each Jira issue has an Affects Version, Target Version, and a Fix Version. Generally speaking Sakai uses these values to indicate:

  • Affects Version - Version(s) in which an issue is observed. This should never be set to a "future" version of Sakai, e.g., Post-2.1.2; issues should only affect Sakai relative to a known existing version.
  • Fix Target Version - Version in (s) for which an issue is resolvedwill be fixed. This could be a "future" version of Sakai, when indicating a future release you expect an issue to be resolved in.

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

Issue Type

Affects Version

Fix Version

Image Removed Bug

Version in which bug was identified.

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

Image Removed 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)

Image Removed 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.)

Image Removed 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 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 release number in which the issue is expected to be resolved. Generally, this is is the next version's first QA release, such as 2.3.0.001.
  • For resolved issues, developers should set the fix version to "Nightly/SVN-trunk", unless they know for sure what release the fix will be incorporated in. As perparations are made for each QA release, the fix version will be updated appropriately. (QA folks will also double-check the fix version at verifcation time to ensure that it is correctly set relative to the release they are testing.)
  • or left as Unknown (the default).
  • Fix Version - Version(s) into which the fix for an issue has been merged. This should almost always be Nightly/SVN-Trunk when first resolving an issue as Fixed, wait to add other versions, such as maintenance branches, until the appropriate merges have been completed.

Further notes on Version Numbers

  • QA Versions (e.g., 2.4.0.001, 2.4.0.002, ...) – After a release is made, the interim QA release versions are merged into the "whole" version release number. For example, 2.2.1.001, 2.2.1.002, and 2.2.1.003, were the three QA releases for that version, and they were merged into 2.2.1. The merging is

...

  • necessary for keeping it simple to search, filter, and view issues for released versions of Sakai

...

Further notes on Version Numbers

  • ; 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.
  • Branch versions as Affects Versions (e.g., Nightly/SVN-Trunk, 2.3.x, 2.4.x) – Limit the use of When using a branch version as an Affects Version, please also try to when test the same issue is known to not be present in a to see if is also an issue for the last previously tagged version. This is important because branch versions are moving targets , what is Nightly/SVN-Trunk one day is not necessarily the same the next , so it is genereanlly generally more important to know if an issue affects a released version. Also, such issues are treated as transient issues and will not necessarily need to consume valuable QA resources once they are resolved. Wiki Markup*Branch versions as Fix Versions* (_Issues that only affect a branch version are generally quite rare.
  • Branch versions as Fix Versions (e.g._, Nightly/SVN-Trunk, 2.3.x, 2.4.x) -- As fixes are checked into a branch, they should have their Fix Version updated from the version the issue was estimated to be addressed in (_e.g._, "2.4.0 \[Tentative\]") to the branch's version (_e.g._, Nighlty/SVN-Trunk). Generally, the only branch version a developer needs to be concerned with is – Generally the only branch version a developer needs to be concerned with is Nightly/SVN-Trunk. Only the Branch Manager or project team members dealing with maintenance branches will need to worry about adding other branch versions (_e.g._, 2.3.x, 2.4.x) as Fix Versions; and, those versions should only be used when the fix is actually checked-in to the branch, it should not be used as an indication that one would like a fix checked-in. This will ensure that the issue continues to appear listed in the correct place in the shared Jira filters.

Maintenance Branch Version Numbers

A ".x" version is used to track issues relating to maintenance branches. For instance, 2.24.x is the version number representing the post- 2.2.2 4 release's maintenance branch. This version number should only be used by the maintenance branch manager as a Fix Version. It is used to indicate that for a particular Jira the associated revisions have also been merged into the maintenance branch, in addition to trunk.

If someone is basing their deployment on a maintenance branch, then it may be used as an Affects Version, however, be forewarned of the potential for confusion since the maintenance branch is a moving target. In such a situation it is important to indidate the revision number in the issue, either as part of the Summary, an additional Comment, or in the Environment field, so that folks know to which version revision of the maintenance branch you are referrning. It is also highly likely that the release version the branch is based on is also affected, and should also be flagged as an Affected Version.

Anchor
Priority
Priority
Priority

...