Filing Issues

Affects Version/s should only be set to the version it was discovered in - it is implied that the issue will persist until it is fixed. If an issue is reopened (a regression), a new version should be added to the list (but leave the old one). If your version is not listed and it is a release, this is a problem and you should email Nick Bastin or Rob Sherwood right away. If your code is from mercurial, please choose the closest released version number and then put the mercurial banch and hash (of the revision closest to your current on that is in the main repo - if you have local commits don't post those hashes) in the "Environment" field of the bug report.

Fix Version/s should be set to Next if we expect to fix this in the very short term, or Long Term if we expect that it will take some research or is significantly lower priority. All issues will be evaluated by the core team during release planning and Fix Version will be changed as appropriate.

A note about Next and Long Term. Next does not literally mean the next released version - it intends to mean the next planned release, but if we release a version for a specific deployment then the version number will be incremented and not all bug fixes from Next will be magically fixed and present. What Next literally means is that it is on the table for the next release, and someone will have to make an explicit decision to cut it, while Long Term means that planned releases will go out the door without these fixes unless we get a patch for them, or they are moved into the Next bucket.