RepoDNA v1.4.1: Preparing Native WinGet Installation and Upgrades for Windows

Installing developer tools should be straightforward, and keeping them updated should be even easier.

With RepoDNA v1.4.1, I've introduced the packaging and automation needed to prepare RepoDNA for the Windows Package Manager (WinGet) community catalog.

RepoDNA is an open-source, local-first repository intelligence platform that helps developers understand their codebases through architecture analysis, dependency exploration, repository history, and evidence-backed reports.

What's new in v1.4.1?

1. WinGet package manifests

The release introduces manifest generation for two separate Windows packages:

• SanskarIN.RepoDNA — RepoDNA desktop application.
• SanskarIN.RepoDNA.CLI — RepoDNA command-line tool.

Both packages are prepared for Windows x64 and ARM64.

2. Preparing native installation and upgrades

Once Microsoft accepts and indexes the packages, Windows users will be able to discover them through WinGet.

For example:

winget source update
winget search --id SanskarIN.RepoDNA --exact

After the community listing becomes available, users will be able to install the package using:

winget install --id SanskarIN.RepoDNA --exact

And when a future package version is published:

winget upgrade --id SanskarIN.RepoDNA --exact

Important: The v1.4.1 release generates the necessary manifest files, but publishing on GitHub does not automatically make a package available in Microsoft's WinGet catalog. The manifests must be submitted, accepted, and indexed.

3. Release integrity and automation

The release process now prepares six YAML manifest files, covering version metadata, locale information, and installer definitions for the two packages.

SHA-256 hashes are calculated from the actual release artifacts rather than entered manually.

An optional GitHub Actions workflow also helps maintainers submit these manifests for Microsoft's review.

4. Regression testing

New tests cover:

• Generated package hashes.
• Portable archive executable paths.
• Supported CPU architectures.
• Missing input artifacts.
• Unsupported version strings.

These checks help keep the package generation process consistent as RepoDNA evolves.

Why this matters

RepoDNA already offers desktop, CLI, browser, and WebAssembly-based workflows.

A well-maintained WinGet listing will provide another installation and update path for Windows users.

Future releases will still need their own accepted manifests, but the automation introduced in v1.4.1 makes that process easier to maintain.

Try RepoDNA

GitHub release:
https://github.com/sanskarIN/RepoDNA/releases/tag/v1.4.1

Live web app:
https://sanskarin.github.io/RepoDNA/

WinGet documentation:
https://github.com/sanskarIN/RepoDNA/blob/v1.4.1/docs/winget.md

If you're maintaining a Windows application through WinGet, I'd be interested in hearing how you handle package submissions, installer validation, and upgrade testing.

Thanks for following RepoDNA's development! 🧬