Upgrading repowise

July 28, 2026 · View on GitHub

repowise is built so that upgrading is painless: upgrade the package, run repowise update, and your existing index keeps working. A full reindex is only ever recommended for a genuinely breaking change, never forced, and repowise tells you exactly when and how.

The short version

pipx upgrade repowise      # or: uv tool upgrade repowise / pip install -U repowise
cd your-repo
repowise update            # picks up the new version against your existing index

That's it. No reindex in the normal case.

What happens on upgrade

When you run repowise update (or repowise serve) after upgrading, repowise:

Reads your store's format version and compares it to the running build. The on-disk store records which version wrote it, so repowise knows exactly what, if anything, an upgrade needs.
Applies any automatic, no-cost adjustments in place. New database columns are back-filled automatically. If your embedding model changed, vectors are re-embedded for you (no LLM calls). You don't run anything.
Keeps your parse cache warm. Ordinary releases do not invalidate cached work, so updates stay fast.
Shows you what changed. A short "what's new" summary appears for the versions you crossed, and repowise whats-new shows release notes any time. The web UI surfaces a dismissible "update available" banner and a what's-new view.

When a reindex is recommended

Rarely, a release changes the store format in a way an in-place migration can't cover. When that happens repowise keeps your existing index working and shows a clear notice with the exact command, for example:

Reindex recommended: repowise init --force

It is a recommendation, not a requirement. Nothing is wiped until you choose to run it. You can keep using the current index and reindex when convenient.

Behaviour changes worth knowing about

`health-rules.json` globs now match like `.gitignore`

Per-path rules in .repowise/health-rules.json used to be matched with fnmatch, where * crossed directory separators. They now use the same gitignore matching as exclude_patterns, .gitignore and the file traverser, so one glob means one thing wherever you write it.

What changes for you: a single * stops at a path segment. A rule written as src/legacy/* used to silence the whole subtree and now covers one level, which means biomarkers you had turned off can start firing again.

The fix is one character:

- {"path": "src/legacy/*",  "disabled_biomarkers": ["complex_method"]}
+ {"path": "src/legacy/**", "disabled_biomarkers": ["complex_method"]}

You do not have to hunt for them. Any affected pattern logs a warning naming the pattern when the file is loaded:

health_rules_glob_narrowed pattern=src/legacy/* hint='*' no longer crosses '/' …

Patterns without a /, patterns already using **, and directory prefixes like vendor/ are unaffected.

Checking your version

CLI: repowise --version, or repowise doctor for an update check with the right upgrade command for your install method.
Web UI: the version is shown in the sidebar footer, with a dot when a newer release is available.