Bug 505193

Summary:	"Version First Reported In" is a wrong change
Product:	[Websites] bugs.kde.org	Reporter:	David Edmundson <kde>
Component:	code customizations	Assignee:	KDE sysadmins <sysadmin>
Status:	RESOLVED INTENTIONAL
Severity:	normal	CC:	nate, sheedy
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description David Edmundson 2025-06-04 06:19:16 UTC

We used to have a field called Version. 
It was incorrectly used as a mix of "version last seen in" and "version last seen in". It has then been changed to be always the bad version.

The reason the latter is better:
 - There's a regular pattern of "does it still happen in version X". If the version information contains this information it's easy. If it's always the first version reported against it's useless.

 - Users can say "this still affects the new version" without us having to read through comments or have people bump the threads
 
 - you can always find out the first version by reading history. You can't find the latest version based on the version first reported in

 - we occasionally bulk mark needsinfo on old versions.

Comment 1 Ben Cooksley 2025-06-04 06:37:52 UTC

This was requested in Bug 504278 - Nate please comment here.

Comment 2 Nate Graham 2025-06-05 16:47:31 UTC

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.

Comment 3 Nate Graham 2025-12-22 21:39:16 UTC

No response; assuming that explanation was sufficient. :)