FluxMarkdown uses a tag-first release workflow driven by a singleDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/xykong/flux-markdown/llms.txt
Use this file to discover all available pages before exploring further.
make release command. The version number is derived from the .version file and the git commit count, ensuring the version embedded in the DMG, the GitHub release, and the Sparkle appcast are always consistent.
Versioning
Versions follow theX.Y.Z format:
- X — major version (breaking changes)
- Y — minor version (new features)
- Z — build number, equal to the git commit count at the time of tagging
.version file stores only the X.Y base (e.g., 1.13). The full version is computed at release time:
CHANGELOG workflow
Every merged PR should have a corresponding entry in the[Unreleased] section of CHANGELOG.md before a release is cut.
Step 1: Analyze the PR
CHANGELOG.md and add the entry under ## [Unreleased] using the format:
Added, Fixed, Changed, Removed, Deprecated.
Step 3: Commit the CHANGELOG update
CHANGELOG entries for architecture, build, test, CI, and refactoring changes are kept in
CHANGELOG.md but filtered out of the public GitHub Release notes by scripts/release.sh.Release steps
Ensure all PRs are recorded
Verify the
[Unreleased] section of CHANGELOG.md contains entries for all merged PRs since the last release. Run ./scripts/analyze-pr.sh <PR_NUMBER> for any that are missing.What make release does automatically
The
scripts/release.sh script executes the following in order:- Reads
.versionand calculates the full version from the current commit count. - Creates the git tag at the current commit (before any version bump commit) so the tag points to the last feature commit, not the release commit.
- Updates
.versionwith the newX.Ybase. - Moves
[Unreleased]entries to a new versioned section inCHANGELOG.md. - Builds the TypeScript renderer (
npm install && npm run build). - Generates the Xcode project (
xcodegen) and builds the macOS app. - Packages the
.appinto a DMG usingcreate-dmgwith Retina support. - Generates
appcast.xmlviascripts/generate-appcast.sh(signs the DMG with the Sparkle private key). - Commits
.version,CHANGELOG.md, andappcast.xml. - Creates the GitHub Release with the DMG attached.
Verify the release
Check the following after the command completes:
- GitHub Release exists at the correct tag
- DMG is attached to the release
appcast.xmlin the repository contains the new version entry- All version strings match: git tag, GitHub Release title, DMG filename,
appcast.xml
Update Homebrew
xykong/tap) and the official homebrew-cask draft file. See the Homebrew distribution guide for details.DMG build
The DMG is created withcreate-dmg. It uses a custom background image and supports Retina displays. The output is written to build/artifacts/FluxMarkdown.dmg.
Key create-dmg options used in the build script:
Sparkle appcast
FluxMarkdown uses Sparkle for in-app update delivery. Theappcast.xml file at the repository root is parsed by the running app to detect new versions.
<item> entry to appcast.xml. The signature allows Sparkle to verify the download before installing.
GitHub release
The GitHub Release is created automatically byscripts/release.sh using the GitHub CLI:
CHANGELOG.md — internal entries (architecture, build, test) are excluded. Only user-visible changes appear in the public release.
Recovering from a failed release
If the release command fails partway through:- Delete the tag if it was created:
git tag -d v<VERSION> && git push origin :refs/tags/v<VERSION> - Delete the GitHub Release if it was created:
gh release delete v<VERSION> - Revert any version commit:
git revert HEAD - Fix the root cause, then run
make releaseagain from the beginning.
Homebrew distribution
How to update the tap cask and submit to the official homebrew-cask repository.
Architecture overview
How the Swift host and TypeScript renderer work together.