Redesigning the screens before the release
I spent a long session on my personal video-watching app, starting with a review of which parts of the interface were redundant or confusing. The biggest change was a visual refresh with a sidebar on wide screens and a tab bar on phones, plus per-panel playback controls in place of a single Play All button.
Discussion came first. Most of the time went into deciding what to remove, not what to add, and the result is a smaller set of screens that each do one job.
Shipping it as a tagged release
The work was merged to the main branch, pushed, and tagged as a dated release. The release notes cover the new interface, a change in how unsubscribing interacts with saved videos, several security fixes including a path-traversal fix in file serving, and a bug where users were logged out every day.
The release is saved as a draft rather than published, so I can read it before it goes live. The Docker image build was still running when the session ended, so I have not confirmed it passed.
Upgrade notes worth writing down
The most useful part of the session was writing down what an upgrade will ask of people. Database migrations run on startup. The data directory must be writable by the container, because the login secret now lives there. Anyone using login signs in once after upgrading.
There is also a list of API changes for the companion apps: dates now end in a UTC marker, the verify call can return a renewed token that the client should store, imports no longer subscribe to channels, and request sizes are capped. Writing those down in the release notes is cheaper than discovering them in a broken client.