Skip to content

Qt: Log PCSX2 version changes to update_log.txt on startup#14340

Open
Vishrut2403 wants to merge 3 commits intoPCSX2:masterfrom
Vishrut2403:feature/version-track
Open

Qt: Log PCSX2 version changes to update_log.txt on startup#14340
Vishrut2403 wants to merge 3 commits intoPCSX2:masterfrom
Vishrut2403:feature/version-track

Conversation

@Vishrut2403
Copy link
Copy Markdown
Contributor

Description of Changes

Added a small version tracking mechanism that runs on startup. Each launch compares the current version (BuildVersion::GitRev) against a persisted last_version.txt in the settings folder. If they differ, a timestamped entry gets appended to update_log.txt:

[2026-04-20 00:16:38] Updated from v2.7.229 to v2.7.274-1-g5156fc10c

Rationale behind Changes

Currently there is no way to track when a user updated PCSX2, making it difficult to detect regressions or figure out which version broke something. This adds a log with that covers both the auto-updater and manual installs.

Closes #14327.

Suggested Testing Steps

  1. Write an older fake version to the settings directory:
    echo "v2.7.000-fake" > ~/.config/PCSX2/inis/last_version.txt
  2. Launch PCSX2
  3. Check that update_log.txt was created with a correct timestamped entry
  4. Launch again — verify no duplicate entry is added
  5. Delete last_version.txt, launch again to verify only last_version.txt is created and update_log.txt is not

Did you use AI to help find, test, or implement this issue or feature?

Yes. Used Claude to help navigate the codebase and identify the right hook point and existing helpers to use.

@refractionpcsx2
Copy link
Copy Markdown
Member

Wouldn't it make more sense to just keep a log file for the updater?

@Vishrut2403
Copy link
Copy Markdown
Contributor Author

Vishrut2403 commented Apr 21, 2026

Wouldn't it make more sense to just keep a log file for the updater?

Had a look at the updater code, all three platforms do have processUpdate, and they all go through a single call site But after a successful update the app immediately exits to launch the new version, so there's no window to write a log there either. The QtHost approach works because it catches the version change on the next launch after the update. Also noticed AutoUpdater/LastVersion is already stored in settingsm I could use that instead of a separate last_version.txt if that's cleaner.

@refractionpcsx2
Copy link
Copy Markdown
Member

No i meantjust write to the log file from the updater code, since it will get the PCSX2 directory, you can create/append an updater log file and write in there what version you're updating to and what from.

If there's already a setting for it, then it makes more sense to just use that instead of keeping another file

@Vishrut2403
Copy link
Copy Markdown
Contributor Author

No i meantjust write to the log file from the updater code, since it will get the PCSX2 directory, you can create/append an updater log file and write in there what version you're updating to and what from.

If there's already a setting for it, then it makes more sense to just use that instead of keeping another file

Looked more into it, LastVersion is only written when skipping an update so its not really tracking the installed version. writing the log from inside processUpdate is doable since m_latest_version and BuildVersion::GitRev are both available there but it means touching all three platform implementations separately and still wont cover manual installs. Just wanted to flag that

@refractionpcsx2
Copy link
Copy Markdown
Member

Sure, but if you're manually updating, you probably have more of an idea what versions you're installing and don't really need a log :)

Also there's very little reason to manually update when there's an updater available.

@Vishrut2403
Copy link
Copy Markdown
Contributor Author

Sure, but if you're manually updating, you probably have more of an idea what versions you're installing and don't really need a log :)

Also there's very little reason to manually update when there's an updater available.

The windows updater binary doesn't actually have access to any version info, it just move files around. to log the from and to versions, from there id need to pass them as extra command line args which feels like a bigger change.

@refractionpcsx2
Copy link
Copy Markdown
Member

Okay, but I'm still unsure of the benefit of this, if you know roughly what version you were on (or how long since you updated) and what you're on now, you can download individual past builds and do a binary search to find regressions. There will likely only be a few people who will actually do such regression testing and getting old builds and skipping big steps is not a difficult thing to do, if there's a regression since you last updated, it's likely recentsih.

This all just feels a bit jank and not very useful, honestly imo, sorry. Keeping a log of updates done by the updater could maybe be useful and covers most cases of what you're trying to address, but beyond that, I don't know what use it would be.

I guess it's up to what the team think (not my place anymore, just giving my 2c)

@F0bes
Copy link
Copy Markdown
Member

F0bes commented Apr 21, 2026

This is over complicated. I can only see one use case for this where :

  1. User updates from 2.7.a -> 2.7.b
  2. Has an issue with a game
  3. Forgot what version didn't have an issue
  4. Looks at the updater log to help bisect from a known good (2.7.a)

The windows updater binary doesn't actually have access to any version info, it just move files around. to log the from and to versions, from there id need to pass them as extra command line args which feels like a bigger change.

I much prefer that rather than leaving random files on the users disk. Just pass it as an argument when PCSX2 invokes the updater.

Append to an update_log.txt

[yyyy-MM-dd hh:mm:ss] Updated PCSX2 from <old version> to <new version>

@Vishrut2403
Copy link
Copy Markdown
Contributor Author

This is over complicated. I can only see one use case for this where :

  1. User updates from 2.7.a -> 2.7.b
  2. Has an issue with a game
  3. Forgot what version didn't have an issue
  4. Looks at the updater log to help bisect from a known good (2.7.a)

The windows updater binary doesn't actually have access to any version info, it just move files around. to log the from and to versions, from there id need to pass them as extra command line args which feels like a bigger change.

I much prefer that rather than leaving random files on the users disk. Just pass it as an argument when PCSX2 invokes the updater.

Done, passed the old and new version strings as extra args to the updater binary and write to update_log.txt in the destination directory after CommitUpdate succeeds. also needed to add the same args on the AutoUpdaterDialog side where it invokes the updater.

@Vishrut2403 Vishrut2403 force-pushed the feature/version-track branch from f1a20a0 to 51f7027 Compare April 21, 2026 18:48
@Vishrut2403
Copy link
Copy Markdown
Contributor Author

Also added the log for linux and mac inside respective processUpdate implementations in AutoUpdaterDialog.cpp, so it should cover all three platforms now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Feature Request]: Update Log to track pcsx2 version updates on a local hardware

3 participants