Tracker issue versions
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 all the issues that need to be fixed before release. Some important points about the use 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, 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 should be ZERO "must-fix" issues and the version is archived as part of the release process.
- Issues having a "must-fix" affected version must be given absolute priority within the process.
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 really important to mark 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.