Why I Fused 40+ Windows Tools Into One Installer

Hybrid — and the split was deliberate.

Install is all-or-nothing: one installer, one decision. That's the discovery fix you mentioned, and we didn't want to give it back with a package-picker screen.

Updates are not all-or-nothing. Under the hood the payload is split into nine functional sub-packages — main program, the OCR engine platform, the download engine, media tools, and so on — each with its own version number recorded in an update manifest. Every release gets a single release number (that's what the changelog entry, the GitHub tag and the installer filename derive from), but internally only packages whose content actually changed get their version bumped. The built-in updater diffs the manifest against what's installed and downloads only the changed packages.

In practice the main program revs almost every release, while the heavyweight platforms (OCR engine, ffmpeg, aria2) bump once every handful of releases — so a typical update is a small incremental download, not a full re-pull. It also keeps our distribution caches honest: unchanged packages keep pointing at their existing release assets, so nothing gets re-uploaded or invalidated for no reason.

What we deliberately skipped is user-facing per-tool choice — you can't install "just the OCR tool." We considered it, but that means a combinatorial number of install states to test, a package-manager UI to maintain, and "why doesn't feature X work?" support tickets from people who unchecked it at install time. For a free desktop tool, one installer plus package-level deltas captures most of the bandwidth benefit at a fraction of the support surface.

Side note in the same spirit: a lot of the catalog is data rather than code — commands are JSON modules — so growing the tool count doesn't bloat the binary that ships.