stacklok / stacklok/toolhive-studio

Link to release notes before upgrading

Open
#2,006 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
TypeScript
Stars
167
Forks
24
Avg merge
11h 32m
Merged PRs (30d)
91

Description

Summary

When a new version of the ToolHive UI is available, the update UI should include a direct link to the release notes so users can review what's changed before deciding to upgrade.

Motivation

Right now, the update flow asks you to download and install a new version without giving you any easy way to see what's actually in the release. If you're on manual update mode, you see a box with a download button, but no context about what you're downloading. For auto-updates, the confirmation modal has the same gap.

Linking to the changelog before the user commits to an update is a small change that builds trust and helps users make informed decisions about when to upgrade.

Proposed behavior

Manual updates: Add a "View release notes" link alongside the existing download button in the update notification area.

Auto-updates: Add a "View release notes" link in the update confirmation modal, so users can review changes before confirming.

The link should point to the corresponding GitHub release (e.g., https://github.com/stacklok/toolhive-studio/releases/tag/vX.Y.Z).

Related: improve the release notes themselves

Since these release notes will now be more visible to end users, it's worth investing in making them more polished. The current GitHub releases use basic auto-generated notes. The main toolhive repo has a Claude Code skill in progress for generating better-formatted release notes. We should consider adopting the same skill or approach in toolhive-studio for consistency across both repos.

Implementation notes

  • The version number for the pending update is presumably already available in the update check logic, so constructing the GitHub release URL should be straightforward.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the update check logic and trace where the manual update notification and auto-update confirmation modal are rendered. Verify how the pending version is exposed, then add release-note links for both flows pointing to the corresponding GitHub release; the issue names no files or tests to run.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
desktop, frontend
Issue type
Feature
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.