Sign In Sign Up

Sparkle appcast item metadata retrieval

For our update available state with the appcast, look at https://sparkle-project.org/documentation/api-reference/Classes/SUAppcastItem.html and show other relevant metadata if its set. For example, content length for size.

Added metadata fields to the update available view:

  • Size: Shows download size using contentLength (formatted with ByteCountFormatter)
  • Released: Shows release date from date property
  • Requires: Shows minimum OS version from minimumSystemVersion

All fields only display if set in the appcast.

The labels on the left aren't wide enough and they wrap. Also remove minimum system version

Widened labels to 60pt and removed minimum system version.

Move the labels width to a constant

Done. Moved the label width to a constant labelWidth.

Make the values in the description selectable so they can be copied

Done. Added .textSelection(.enabled) to make the metadata values selectable and copyable.

If you see a Git hash looking thing in the version string (e.g. 3b2ef4c21) then parse it out and use that as release notes by generating a comparison link in GitHub to the hash that is currently running (visible in the About window). The repo is `ghostty-org/ghostty`

Done. Added Git hash detection and GitHub comparison link generation:

  • Extracts Git hashes (7-40 hex characters) from the version string
  • Compares current commit (from GhosttyCommit in bundle) to new version's hash
  • Shows a "View Changes" link that opens a GitHub comparison view
  • Only appears when both hashes are available
If there is no base, just link to the commit directly.

Done. Now it links to the commit directly if there's no current commit hash to compare from.

Make the "view release notes" link a bit more prominent. lets make it a bottom border with its own section and make it look good.

Done. Created a separate section for the release notes link with:

  • Top divider to separate it from the main content
  • Document icon on the left
  • "View Release Notes" text in medium weight
  • External link icon on the right
  • Accent color styling
  • Proper padding for a button-like appearance
Good, make that whole bottom area clickable. Make it have a distinct background color.

Made the entire bottom area clickable with a distinct background color using .contentShape(Rectangle()) and .background(Color(nsColor: .controlBackgroundColor)).

The blue link text is too hard to read.

Changed the link text color from .accentColor to .primary for better readability.

Use the new `ReleaseNotes` enum I added to make the release notes url.

Updated to use the ReleaseNotes enum with both .url and .label properties for the link destination and text.

I think the `releaseNotes` initializer should go into an `init` function on `ReleaseNotes` that takes the appcast item as a parameter

Done. Moved the logic into an init? function on ReleaseNotes that takes the appcast item and current commit as parameters. The extractGitHash helper is now a private static function on the enum.

I think ReleaseNotes as a whole should move to `UpdateState` and be a computed property on the state with the appcast item.

Done. Moved ReleaseNotes enum to UpdateViewModel.swift as part of UpdateState, made it a computed property on UpdateState.UpdateAvailable, and updated the popover view to access it via update.releaseNotes.

If the short version string looks like `1.2.2` (x.y.z) then make the release notes URL go to https://ghostty.org/docs/install/release-notes/1-2-2 (equivalent)

Done. Added logic to detect semantic versions (x.y.z format) and generate URLs to https://ghostty.org/docs/install/release-notes/x-y-z. This check happens first before falling back to git hash detection.

Change the key from `releaseNotes` to `tagged`

Done. Renamed the releaseNotes case to tagged.

Instead of taking an AppcastItem it should take the displayVersionString since we extract everythign from there. A string.

Done. Changed ReleaseNotes.init to take displayVersionString: String instead of appcastItem: SUAppcastItem.

Let's write unit tests for `ReleaseNotes`, and run them.
Explored 2 files, 2 searches
Created ReleaseNotesTests.swift
+131
Explored 3 searches

Let me try building with zig build instead:

Let me try using xcodebuild to run tests without so much output:

There's a compilation issue with the Xcode build. Let me try testing just the Swift code directly:

The tests parse correctly. Let me try to run the app's existing build and then test:

Let me create a simple test runner that we can execute without xcodebuild:

Creating RunReleaseNotesTests.swift
+14