This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
See http://netbeans.org/bugzilla/show_bug.cgi?id=212659 which was reported as a new one but actually was fixed by Vita Stejskal long long time ago.
Tomas Z. is right ... this should be not a case for reopen ... original bug was fixed in a build 201002170200, see http://netbeans.org/bugzilla/show_bug.cgi?id=180229#c4 and this one is reported for build 201002152000, see http://netbeans.org/bugzilla/show_bug.cgi?id=212659#c0
Actually the behavior is correct: if bug appears in Dev build after it's marked fixed (there's a couple days buffer taken into account in which we expect fix gets propagated from team repo to dev build), exception reporter "reopens" the bug (by creating new report with appropriate comment. Funny thing about this is that: 1) User reported bug from ~2 years old dev build....which is rather exotic case :-) 2) unfortunately it took 12 days between status FIXED and real propagation of fix, which is more than we expect, and that's why it got reopened. I'd suggest to leave as wontfix, since this is really a rare case, but if you think it's worth fixing, I'll add additional check that for reopening dev build cannot be more than year old or something like that.
The problem is that even small group of "exotic" users may generate a new reports. For components like java.source and parsing.api which have very high usages this may be a problem. The biggest problem is that it's reported as 7.2 issue. Why the version is not 6.9?
(In reply to comment #3) > Why the version is not 6.9? Because Dev build is expected to be nearest future version which is under development ->7.2 in this case.
We cannot prevent them creating reports, but we sure can prevent creating/reopening issues from these reports if you find it worth.
(In reply to comment #5) > We cannot prevent them creating reports, but we sure can prevent > creating/reopening issues from these reports if you find it worth. What about setting Version if Dev in a report based on the build number (date) if applicable (applicable just for official daily builds) ?
This will be solved as a part of EOL process standardization. If this process is inplace (hopefully soon, but no idea when exactly), we will not report bugs from EOLed versions.
just FYI: we currently do not create issues from reports older than 7.1...