Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Tracker issue versions

From MoodleDocs
Revision as of 15:11, 22 May 2019 by Eloy Lafuente (stronk7) (talk | contribs) (some formatting and links (take #1))

Here there are some notes about how we handle both the affected and fix versions fields in the Tracker. To be applied along the whole Process.

Some general and simple rules

  • When filling "affected versions" (creating an issue or triaging it, usually) it's interesting to add there as many versions as possible (as far as they are affected, of course). And ideally not more than 1 version by branch (i.e. don't put 3.6.1 and 3.6.2 together, the former alone is enough).
  • When filling "fix versions" (usually as part of the integration process) a simple rule must be observed: "or stables or master". Never mix them in the same issue. The idea beyond that is to avoid presenting in release notes for the next major release something that has been already fixed in the latest stable minor.

Must fix versions

Part of the process, some weeks before X.Y freeze, the corresponding "Must fix for X.Y" version is created. That version is critical to be able to detect, filter and organize all the issues that need to be fixed before release. Some important points about the handling of those "must fix" versions:

  • They must be added to the "fix versions" field. That's their correct place (there is a [filter in charge of detecting wrong uses|https://tracker.moodle.org/issues/?filter=20021], in order to proceed to fix them).
  • Once the issue is integrated, the "Must fix for X.Y" version 'must be removed'.
  • Once the release happens, there must be ZERO "must-fix" issues and 'the version is archived' as part of the release process.
  • Issues having a "must-fix" fix version 'must be given absolute priority' within the process.

Regression versions

At the same time that a major X.Y version is packaged and released, its corresponding "X.Y regressions" version is created. That version is important to mark and track all the issues (on creation or triaging) that are a direct regression caused by the X.Y release. Some important points about the use of those "regression" versions:

  • They must be added to the "affected versions" field. That's their correct place (there is a filter in charge of detecting wrong uses, in order to proceed to fix them).
  • They are not removed once an issue is fixed. They remain there, in the "affected versions" field forever.
  • Eventually, once a given X.Y version falls out of support and given that there are ZERO unresolved issues with a "X.Y regression" version, the version is archived.
  • Issues having a "regressions" affected version should be given high priority within the process.

See also