Skip to content

Release 1.0.0 - #1

Merged
Pindagus merged 16 commits into
mainfrom
dev
Aug 20, 2026
Merged

Release 1.0.0#1
Pindagus merged 16 commits into
mainfrom
dev

Conversation

@Pindagus

@Pindagus Pindagus commented Aug 20, 2026

Copy link
Copy Markdown
Owner

Merging publishes 1.0.0 to the latest dist-tag, which currently still points
at 1.0.0-dev.1.

It also activates two things that only run from the default branch: the daily
upstream check, and the push trigger that turns future merges into releases.

Exiting to the TizenBrew launcher was verified on a Samsung TV, from the home
screen, from settings and after navigating several pages deep.

Pindagus and others added 16 commits August 20, 2026 15:36
Pins jellyfin-web and jellyfin-tizen so an old release rebuilds
identically, which the previous "always latest" build could not do.
npm rejects a trusted-publishing upload with E422 when the manifest does
not name the repository the workflow ran in, which failed the first
release after the build had already succeeded.
jsDelivr refreshes branch files independently, so dist could serve a mix
of two builds. npm versions are immutable and already cover this.
The readme opened with release machinery a viewer never needs, and
answered server compatibility itself instead of pointing at Jellyfin's.
The package shipped without a readme at all, leaving the npm page blank
and no way to tell which web client a release carries.
These hold working notes rather than project files, and were one
`git add -A` away from landing in the repository.
Release notes already live on the releases page, and the push that kept
a copy in the repository is what branch protection has to block: the
default GITHUB_TOKEN cannot be given a bypass on a user-owned repository.
The commit reached package.json and the npm readme but was never stamped
into the adapter, so the one place a user can read it never had the value.
A single history.back() only reaches the launcher while it is still the
previous entry, but jellyfin-web pushes one per view, so exiting after
visiting settings landed on a jellyfin page instead.
TizenBrew fetches modules from jsDelivr, which holds a dist-tag for twelve
hours, so a TV kept installing the previous build for half a day.
history.length counts the whole tab; react-router's history.state.idx counts
only what jellyfin-web itself pushed. Both agree in a desktop browser, so the
logging is what will identify the difference on a TV.
Removing the hook is what stopped exit working on the TV, so it is tried
first again. Since the remaining paths cannot be reproduced off the device,
the settings block now shows what the last attempt actually did.
Testing on the device showed history.go(-n) is ignored there, the router
index is never set this early, and no launcher hook exists, so everything
built around those possibilities is gone.
Exiting is no longer a caveat now that it works on the TV, so the entry
moves out of the README's limitations and into the reasoning behind it.
@Pindagus
Pindagus merged commit 44f9781 into main Aug 20, 2026
1 check passed
@Pindagus
Pindagus deleted the dev branch August 20, 2026 18:38
@github-actions

Copy link
Copy Markdown
Contributor

🎉 This PR is included in version 1.0.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

@github-actions

Copy link
Copy Markdown
Contributor

🎉 This PR is included in version 1.0.0-dev.7 🎉

The release is available on:

Your semantic-release bot 📦🚀

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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants