https://bugs.kde.org/show_bug.cgi?id=505193
--- Comment #2 from Nate Graham <n...@kde.org> --- I think "version first reported in" is better because it lets us put together search queries for bugs and introduced by version for tracking and project management purposes. I use a bunch of these to track how much we broke per release. And there are a few reasons why I think "version last confirmed in" is less useful than it might seem: 1. Bumping the version to confirm that an issue is still happening in a release isn't useful; instead, a person who wants to do this can simply close the bug report if they find that it no longer reproduces in the release they're testing with. Bug reports can therefore be assumed to be still reproducible in the latest release if they're in the CONFIRMED state. 2. Users don't stop spamming tickets with "this is still happening" comments. Instead they do that in addition to changing the version number. 3. Finding the version by reading the history doesn't work if it was never written in the history by the bug reporter. But often you as the bug triager can figure this out anyway and set the version metadata appropriately. E.g. an Arch user who doesn't report the version can be safely assumed to be using the current released version 99.99% of the time. 4. We don't actually do bulk NEEDSINFO bumps for old bugs, which is good, because these are often quite destructive and we lose legitimate bug reports. But if we did want to, it would also work fine to generate lists of bugs that are UNCONFIRMED and reported n years ago; no need to involve the version field at all. -- You are receiving this mail because: You are watching all bug changes.
