I agree with the point of view. I am however not sure if the average user can use these fields correctly. 

I would like to suggest that a wiki page is created that shortly explains how to use the different fields, and then if possible link to it from this page in BZ.

rgds
jan I.

I hope in 2 years time there will be no more auto-filter problems! :)

IMHO, if bug is not reproducible in 4.0.0 then just mark as Resolved/Fixed and move on.   Is there any good reason to spend additional time on it indicating that you tested on 3.4.1 or setting a target milestone of 4.0.0, etc?  Is that info valuable for anything?  If it is fixed then it is not worth spending more time on it.  My opinion at least.

Also, the practical problem we had with offering more choices on these fields is that users would use them incorrectly.

Finally, we want to encourage users and QA to test with the most recent version.  It is not very useful to test a bug with 3.4.1.  Either the bug is found there or it isn't.  If it is found in 3.4.1 then you still must retest with 4.0.0.  So why not just focus on testing with 4.0.0?

(In reply to Rob Weir from comment #3)
> 
> Finally, we want to encourage users and QA to test with the most recent
> version.  It is not very useful to test a bug with 3.4.1.  Either the bug is
> found there or it isn't.  If it is found in 3.4.1 then you still must retest
> with 4.0.0.  So why not just focus on testing with 4.0.0?

Unfortunately, 4.0 is not as good as 3.4.1.
Quite a few bug reports declared they were rolling back to 3.4.1.
Test with most recent? 
Only when we have continual improvement (like in ISO 9001), but this is not the case in reality.

(In reply to Rob Weir from comment #3)
Hi Rob,
That's a complete misunderstandig of the function of the version related fields. Following your arguments we could simply drop them.

But these fields have an important function to find relations between bugs and code commits, especially for handling of regressions. 

Some Examples:

Version
-------
If I have 2 similar looking bugs (may be Calc-Conditional-formatting does not work in a particular way), tests show that 
- problem 1 of Bug Report 1 with sampledocument1  starts with 3.3.0 
- problem 2 of Bug Report 2 with sampledocument2  starts with 3.4.1
So this difference indicates that although the observed effects are the same, the bugs seem to have different roots

In regressions developer should try to find out what code commit caused the problem, and why it has been introduced. Without that knowledge his changes to solve the current problem might cause a new (old) problem.

Target Milestone
----------------
If it's not only used as a goal, but also to indicate for what Version a bug really has become fixed, the function is similar to Version: If there are bug reports concerning similar looking effects, but one is no longer reproducible with 3.4.1 (=TM), a second one no longer with 4.0.0 (but still), and I 

Latest Confirmation on
-----------------------
If I do a Bug Report cleanup, again for the Calc-Conditional-formatting, I try to find DUPs to the bug I have handled few minutes ago. If I found out that the Bug has been fixed for 3.4.1, I can exclude Bugs with "latest confirmed for 4.0), those ones can not be DUPs of a bug  fixed for 3.4.1.

And so on.

These are some of the query tricks what can be used to work more efficient with Bugzilla. We should not configure the tools for the lusers, but for the experts. Although, of course, I see the problem with wrong handling selectors. But that problem should be used by adjusting permissions, not by limiting contents of selectors to useless remainders

I somehow agree with Rainer.

My scenario which would benefit from the existence of a value like 'pre 3.4.0' for field Version:
In the last days I reviewed certain defects reported on version 4.0.0 - value of field Version = 4.0.0. My investigation reveals for some of them already occur in AOO 3.4.0, but not in OOo 3.3.0. Thus, I changed value of field Version to 3.4.0 while setting Latest Confirmation on to 4.0.0. Some are reproducible in OOo 3.3.0 as well. Here, I also changed the value of field Version to 3.4.0 loosing the possibility to distinguish between these issues.

My opinion of field Target Milestone:
This field should only be set, when it is 100% clear that the issue is solved in a certain version - as it is more or less documented. To request a solution for a certain version we are using our flags. Thus, may be it makes sense to restrict the access to this field to the corresponding group.
And yes - as Rainer said - having values for former releases would enable us to document that a submitted issue from a user using a former version has been fixed in an already available release. This is not really critical, but would have a documentary purpose.

I am not sure, if we would need values for former released versions for field Latest Confirmation on, when we would have values for former released versions for field Target Milestone. For solved issues we have Latest Confirmation on == Target Milestone - 1

If BZ adims think that number of available versions might confuse unexperienced users (I think that would be a real problem with the VERSION selector) they should find a way to hide those selectors for that user group or limit the number of visible versions for those users. But destroying the expert's tool is not an appropriate solution.

I'm going to add all Bug reports with inappropriate version information here to "See Also" so that it will be possible to repair that later. 
Lacking sense to see the problem is really daunting.

I add Lacking sense to see the problem is really daunting.

I add Bug 119006: TM 4.0.0 is not plausible for a problem reported with the same version and also (possibly) 4.0.1

Rainer, the Target Milestone field is not for indicating what release a defect was fixed it.  That field is for a developer to indicate when they are planning on fixing a bug.  For example, some bugs might be targeted to a 4.1 while others are targeted to 4.0.1.  But developers don't always deliver fixes per their original intentions.  For example, I recently cleared the milestone field for a bunch of unfixed issues that had target milestone set to 4.0.0 and 4.0.1.  

If you want a "fixed version" field added to BZ then please make a proposal for this on the dev list.  In fact, if you want any non-routine changes to the bug tracking process currently in use in the project please make a proposal on the dev list.  This is not something that 3 or 4 people are going to change in side discussion on a BZ issue.

Hi Rob,
I know how Target Milestone is used, and that's completely ok, no appeal from my side.

But we urgently need reliable ("query proof") TM information for FIXED bugs, what allows some sorting of possible DUPs, and together with "VERSION" and "Latest Confirmation" QA staff with no (like me) or only few C code knowledge this version info is a very powerful and important indicator for relations between bugs.

So the simple request here is not to hinder QA staff by breaking tools, please reenable all AOO versions including the "Pre-3.4.0" for general use in all version selectors. Some few wrong use of the selectors by unexperienced users is much more tolerable than a (more or less) complete cut-off.

Rainer,that's not my decision.  Make a proposal on the dev list and if there is consensus then I will be happy to help.

To be honest I will argue against such a change, but neither my opinion nor yours alone will decide this.

(In reply to Rob Weir from comment #9)
Your explication is correct for Bugs with A status before fixed and wrong with status FIXED. When the Bug becomes fixed developer inserts the Version with with what the fix will be available. If a bug has becomes fixed without any action for the particular bug (because the fix is integrated in a fix for an other (unknown) bug report or during normal progress of the progress, the one who checks the bugs selects the oldest version for what the bug no longer does exist. This information helps to distinguish bugs with similar symptoms. 
 
There is no need for an extra field.