Skip to content

chore(release): label the fork 0.5.5-sixth.1 - #42

Merged
aaroncoville merged 1 commit into
theme/sixth-historyfrom
chore/version-0.5.5-sixth.1
Oct 6, 2026
Merged

aaroncoville merged 1 commit into
theme/sixth-historyfrom
chore/version-0.5.5-sixth.1

Conversation

@aaroncoville

Copy link
Copy Markdown
Owner

Labels the fork 0.5.5-sixth.1: parity with upstream public 0.5.5 plus the themed branch. The updater compares it as 0.5.5, so the releases notifier stops offering upstream 0.5.5 and still offers 0.5.6 and later. A test reads the real package.json version and pins both behaviours.

Not verified: electron-builder packaging with a prerelease semver (only the vite build was run).

The fork carries upstream's public source up to and past its 0.5.5 tag,
plus its own theme and fixes, but package.json still said 0.4.6, the
last version upstream's public source declares. The app therefore
described itself as two releases older than it is. Its releases/latest
check also offered upstream's 0.5.5 installer as an update, even though
this build already contains that public source.

The version is now 0.5.5-sixth.1, in package.json and package-lock.json.
The updater compares major.minor.patch and discards the suffix, so the
label reads as 0.5.5: upstream's 0.5.5 is no longer offered, and 0.5.6 or
later still is. A test reads the real package version and holds it to
both. On the first launch after the upgrade from 0.4.6 the release notes
open once, as for any upgrade.
@aaroncoville
aaroncoville merged commit 9bea72c into theme/sixth-history Oct 6, 2026
@github-actions

github-actions Bot commented Oct 6, 2026

Copy link
Copy Markdown

🚫 This PR is missing its before/after evidence

Every pull request here has to show its work. Screenshots or a short screen recording, before the change and after it.

  • Before — no image or video under that heading
  • After — no image or video under that heading

How to fix it: edit the description, keep the ### Before and ### After headings from the template, and drag an image or video under each. GitHub uploads it inline. This check re-runs the moment you save.

A bug fix with no visible surface still needs it: show the failing behaviour, then the same steps passing. A terminal recording is fine.

Genuinely nothing to show — a CI tweak, a typo, a dependency bump? A maintainer can apply the no-visual-change label. Please don't ask unless it truly has no observable effect.

📖 CONTRIBUTING.md → Evidence is mandatory

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant