Hi geizer,
It is good that you brought up the topic. I had submitted a couple of filter ideas to MC staff before but your bringing this to mind caused me to refine some of those suggestions.
I am guessing that each bug tracker entry (bug or feature) probably already has a beginning version number and an ending version number. I am guessing we just do not see it. They would be much like the examples below.
Code: Select all
Start Version End Version
New feature request 9999.9999 9999.9999
Old bug 2.1999 6.0000
Recent bug (not fixed) 6.0000 9999.9999
New Feature just in 7.0000 9999.9999
I created a few filter ideas that would use these bug tracker version start/end fields.
View all new features implemented and existing bugs too
Code: Select all
If Start-Version <= Filter-Version and End-Version >= Filter-Version then
include it in the list
You can see from this that everything stays in the file but your filters determine what you will see (removing the clutter you complained about). When a bug is closed it gets an end version number change to match the last version it occurred in. I think it should be the MC staff who set this end-version number because they will know the exact number at which it last occurred in. If they have it programmed properly, it will be easy for them since they will be clicking a line in a list of versions of MC and the program will pop the number in to the bug tracker record (no need to key in this long number). If the Version-End is used at the time a user clicks the close button it will not be accurate and future filters that may be implemented will not be accurate.
This would be the filter to see only current bugs to vote on.
Code: Select all
If Start-Version <= Filter-Version and End-Version >= Filter-Version then
If Type is a bug then
include it in the list
Searching for feature requests to vote on
Code: Select all
If Start-version = 9999.9999 and End-version = 9999.9999 then
Include this new feature request item in the list.
Seeing "Start version" / "End version" in our personal submission list (including follow-up).
As far as the user looking at their features and bugs they have reported I feel personally that they should see the "Start version", and "End version" in their list. Three uses:
1/ If they have a huge list maybe they could filter their own list to eliminate what they see from an "End version" perspective. So as an example, if the bug tracker had have been around during version 2.1.9999 I may want to filter out all that old stuff.
2/ Also the person who likes to hold back on upgrading can view their list and see when their bug was fixed using the End-version number and decide where to upgrade too.
3/ A variation on the person who holds back is a situation where the person jumps up to the latest version and finds a problem. They can find the bug in the bug tracker, figure out the starting version for that bug and go back to the version before that bug. In this case they reduce the amount of jump forward and wait for that specific bug to be fixed. I have had this happen 2 times where I had to hold back. Only if the version-End is accurate can this be done.
I have linked this thread post to that other thread I created earlier where I requested a few other more extensive filters.
viewtopic.php?f=1&t=8806
John