As discussed at the recent developer meeting, we have been using the “release” field in the bug tracker to mean several different things. Reports are usually submitted with the release field set to the version number in which the bug was observed. Then sometimes we’ve been changing the field value to be “dev” if the problem is also present in the current development sources or if the fix will only go on the development version, etc. I think that changing the version info in a bug report that way can cause some confusion. I wasn’t sure how we could improve things until yesterday during the meeting when I discovered that the bug tracker offers additional release fields “fixed release” and “planned release”. I’ve now enabled these fields and would like to start using the following guidelines for how to use the release-related fields:
release: Usually set to the release where the problem was first observed by the original submitter. The value of this field should only be changed if it was initially set incorrectly.
planned release: Set to the target release for fixing the problem, if known. Available values are currently “8.1.0 (current stable)” and “9.1.0 (current default)”. Set this value to the release you are targeting if you are working on the bug and wish to declare that the problem is expected to be fixed in the next stable release (major or minor release) or the next major release. The value can always be bumped to the next major release if a planned fix doesn’t happen in time for the next release.
fixed release: Once a problem is fixed, set to the next release that will contain the fix. Available values are currently “8.1.0 (current stable)” and “9.1.0 (current default)”.
To avoid confusion, I configured these new fields so that they are only shown to project members on the initial bug report submission page (if that’s not correct, let me know).