If someone is basing their deployment on a maintenance branch, then there is the potential for confusion when using it as Affects Version, since the maintenance branch is a moving target. When reporting issues, it is important to indicate the revision number in the issue, so that folks know to which revision of the maintenance branch you are reporting the issue against. Even better is to determine if the issue affects the last maintenance release, and, if it does, use that as the Affects Version instead.
The Priority field in Jira is used by Sakai to reflect a combination of issue characteristics, including:
In practice, the Jira Priority field is utilized by Sakai at two times: during prioritization of feature requests/branches/contributed patches for implementation or merging, and when making decisions on what will actually appear in a release. Initial priorities, when an issue is first reported, may be changed to reflect needs as a release moves forward and priorities evolve. Every issue comes in as Major priority and each Jira is triaged to determine the appropriate priority.
As a release date approaches, priorities will also be adjusted - and lowered, if necessary - to reflect the decreasing availability of time and resources.
Basic Definition for Sakai
|Impact on previous releases||Examples|
Release will not be completed until issue is resolved. An example would be a severe problem that bridges multiple tools, or prevents core functionality in one tool.
|Backported at least 2 major version (if applicable/affects). Potentially more than 2.|
Issue will most likely be resolved for release.
|Backported 1 major version back. 2 if applicable/affects and if no code conflict.|
Issue should be resolved for release.
|Backported 1 major version back if no code conflict|
(Previously also Trivial)Minor
Issue may be resolved for release.
|Issues that might be resolved before a release|