Releasing
A release is a GitHub release tagged vX.Y.Z with these files attached:
JBrowser-Setup-X.Y.Z.exeandJBrowser-Setup-X.Y.Z.exe.sha256: the installer and its checksum. Installed copies look for exactly these (automatic updates).
Publishing the release is all it takes to update everyone.
One-time setup#
winget install GitHub.cli
winget install JRSoftware.InnoSetup
gh auth login # GitHub.com → HTTPS → sign in with a browser
git can come from Git for Windows or from GitHub Desktop, which bundles it; the scripts find either. They push with
the GitHub CLI's sign-in, so git needs no credentials of its own.
The version#
jbrowser/__init__.py holds __version__, the single source of truth. The build,
the installer, the exe's version resource and the updater all read it.
.\.venv\Scripts\python.exe tools\version.py # print it
.\.venv\Scripts\python.exe tools\version.py --set 1.5.1 # set it (also rewrites tools\version_info.txt)
Versions are major.minor.patch: a patch for fixes only, a minor for new features, a major for big or breaking
changes.
Every release#
- Write the release notes. In CHANGELOG.md, rename
## [Unreleased]to## [X.Y.Z] - YYYY-MM-DD, or add that section. Its text becomes the GitHub release notes, the text of the in-app Update dialog and the changelog page of this website. Write it for users. - Set the version and commit:
powershell .\.venv\Scripts\python.exe tools\version.py --set X.Y.Z git commit -am "JBrowser X.Y.Z" git push - Release:
powershell .\tools\release.ps1 # add -Draft to review it on github.com firstThe script checks the GitHub sign-in and that the working tree is clean, builds the installer, tagsvX.Y.Z, pushes the tag and creates the release with the notes and both files. - Check it. Open the release page, and in an installed JBrowser use Settings → About → Check now.
If something goes wrong#
| Problem | Fix |
|---|---|
| "GitHub CLI is not signed in" | gh auth login |
| "CHANGELOG.md has no '## [X.Y.Z]' section" | add it (step 1) |
"There are uncommitted changes" (release.ps1 alone) |
commit or discard them |
| "Release vX.Y.Z already exists" | set a new version |
| The build fails because JBrowser runs from the build folder | close that copy and run again |
| It stopped half-way | fix the cause and run the same command again: a tag already on this commit is reused |
| A bad release is out | delete it on GitHub, or mark it pre-release so the updater ignores it, then ship a patch |
Windows PowerShell and native tools
Run the scripts directly. Redirecting all their output (*>&1) in Windows PowerShell 5.1 turns a native tool's
progress messages on stderr (PyInstaller's, for example) into errors, and the scripts stop at the first one.
A draft or pre-release is invisible to the updater, because
GitHub's releases/latest API only returns full releases. Use a pre-release to share a test build without updating
everyone.