What we are building next, and what we have decided not to build.
There are no dates on this page. We shipped twelve minor releases in the thirty-one days to 2026-08-18, roughly one every two and a half days. Any quarter printed here would be wrong in the slow direction, and a roadmap that is wrong in the slow direction is worse than one carrying no dates at all. What we commit to is the status column. The changelog is the evidence, and it is the fastest way to check whether this page is honest.
Items disappear from this page when they ship. If you are looking for something that used to be here, it is in the changelog.
| Status | What it means |
|---|---|
| In development | Being worked on now. Code exists, it is not finished. |
| Planned | Committed to, not started. |
| Exploring | We think it is a good idea and have not committed to it. Tell us if you need it, that is what moves a row up. |
The same vocabulary describes the commercial surface in docs/business/COMMERCIAL.md, where each capability also carries a GA marker when it is available today.
Every language repowise supports ships in the open-source distribution under
AGPL-3.0. No language sits behind the commercial licence, and none will. If
your stack is on this list, the support arrives in pip install repowise.
Languages land on a five-rung ladder rather than a yes/no list, because "do you support X" has five different useful answers. Each rung is defined, with what it buys you, in docs/layers/LANGUAGE_SUPPORT.md. Today that ladder covers 41 languages, 27 of them parsed to a full AST.
| Language | Status | Why it is on the list |
|---|---|---|
| PL/SQL | Planned | We already parse SQL through sqlglot. Packages, procedures and triggers are where the business logic actually lives. |
| ABAP | Exploring | The same argument as COBOL, in SAP estates. |
| RPG / AS400 | Exploring | Named alongside COBOL often enough to track. |
| Fortran | Exploring | Scientific and engineering codebases with long lifespans and thin documentation. |
| Apex | Planned | Salesforce estates, where the org is often the least documented system a company runs. Apex is Java-shaped, and Lightning Web Components are already covered as JavaScript and HTML. |
| Ada | Exploring | Defense and aerospace, long-lived and thinly documented, and usually in the same estates asking about COBOL. |
| Template dialects (Django/Jinja, ERB, Blade, Thymeleaf, Go templates) | Planned | Today they parse cleanly as HTML and yield nothing, because {% extends "base.html" %} is plain text to an HTML parser. A stated ceiling, not an oversight. |
| Language | Status | Next |
|---|---|---|
| COBOL | Planned | Copybook resolution, source-format normalization, broader dialect coverage, and health markers |
| Vue, Svelte | In development | Options-API members, {#each} and v-for head bindings, .svelte.ts rune modules |
| C#, Scala, Ruby | Planned | Dataflow dialects, which is what Extract Method needs in order to lift a span safely |
| Kotlin | Exploring | Dataflow is blocked on the grammar and needs either a grammar upgrade or a text-based jump seam. We would rather say blocked than planned. |
| C | Planned | It shares the C++ grammar for parsing but reaches no health walker map, so it gets graph coverage without markers |
| SQL / dbt | Planned | Column-level blast radius |
| Object Pascal | Planned | Assertion and performance markers, a dedicated uses resolver |
| Elixir | Planned | Health markers, and a call-resolution strategy so a bare-name call reaches beyond its own file |
| F# | Planned | Health markers, and a resolver that reads the AST index instead of the declared-name regex |
| Objective-C | Planned | Health markers, a resolver that reads the Xcode project rather than file stems, and pairing a header with its implementation across files |
| Razor / Blazor | Planned | @using and @inject edges so component tags resolve through imports, @code members as symbols rather than call edges only |
Adding one touches per-language subpackages rather than the parser core, which is what makes this tractable at the rate above. Open an issue and we will scope it in public. Commercial customers can have a language or framework built and maintained by us as a line item, which is GA today, and the result still ships to everyone under AGPL.
Plenty of the code most worth indexing has never been near a git remote. It sits in Perforce, in Subversion, or on a mainframe under a change-management system older than most of the people maintaining it.
A repository with no git at all already indexes today. Only one of the five
layers is derived from history; the graph, documentation, decisions and
code-health layers are all computed from the working tree. Point repowise init
at a plain directory, an export, or a Perforce or SVN workspace and those four
build normally. What is missing is the history-derived half: hotspots, ownership,
co-change, bus factor, bug history, and change risk, all of which need a commit
log to mine.
Closing that gap means teaching the history layer to read something other than
git log. The signals above it do not care where the history came from once it
is normalized into changes, authors, timestamps and touched files, which is the
shape every one of these systems has.
| System | Status | Shape of the work |
|---|---|---|
| Perforce Helix Core | Planned | Changelists map to commits almost directly, and p4 filelog and p4 annotate cover history and blame. Common in games, hardware, embedded and anywhere the repo carries large binaries. |
| Subversion | Planned | Revisions map cleanly; svn log and svn blame are close analogues. Still the system of record in a lot of long-lived estates. |
| TFVC (Azure DevOps) | Exploring | Changesets, for shops on Azure DevOps that never moved to its git repos. |
| Mercurial | Exploring | Changesets map cleanly, and the work is small. Ordered by demand rather than difficulty. |
| CA Endevor SCM (Broadcom) | Exploring | Not a commit DAG. Endevor tracks elements moving through a stage and environment promotion hierarchy, so the practical shape is an export to a filesystem plus a history adapter that reads element history rather than a log. Pairs with the COBOL estates above. |
| ChangeMan ZMF (OpenText) | Exploring | The same argument, with packages instead of elements. |
Ask, do not guess, if your system is not listed. The seam is the same for all of them, and what decides the order is which ones customers actually run.
Real systems are not one repository, and the interesting failures live in the gaps between them.
| Item | Status | What it adds |
|---|---|---|
| Cross-repo intelligence at scale | In development | Hotspots, dead code and ownership across a whole estate with centralized dashboards, beyond the local-workspace scope already shipping in open source |
| Column-level blast radius for SQL / dbt | Planned | Lineage is table-level today through ref() and source(). Column-level answers "who breaks if I drop this field" |
| Organisation-wide change policy | Planned | Local change policy ships today (POLICY.md). This adds central policy management across repositories, approvals and a policy audit trail |
These sit on the hosted platform and the commercial licence. Current availability, including everything that is GA today, is in COMMERCIAL.md §5.2.
| Item | Status |
|---|---|
| GitHub Enterprise, Azure DevOps, GitLab self-managed, Bitbucket | In development |
| SAML / OIDC SSO (Okta, Entra ID, Auth0, Google Workspace) and SCIM provisioning | In development |
| Slack and Microsoft Teams beyond security alerting: hotspot drift, bus-factor warnings, decision staleness, routed by ownership | In development |
| Jira risk-finding links and PR-impact auto-comments on linked issues | Planned |
| Native SIEM connectors (Splunk, Datadog, Elastic) beyond the signed-webhook stream | Planned |
| PagerDuty | Planned |
| SPDX SBOM output and cross-format conversion | Planned |
| ISO 27001 Annex A and GDPR / data-residency control mappings | Planned |
On that last row: we would rather ship two solid compliance mappings than four shallow ones, which is why PCI-DSS 4.0 and SOC 2 are GA and these are not.
| Item | Status |
|---|---|
| Role-based access control at repo, module and decision level | Planned |
| Air-gapped install bundle with bundled grammars, embedding model and optional Ollama runtime | Planned |
| Helm chart for the reference topology | Planned |
| Multi-tenant deployment | Planned |
| Backup and restore, point-in-time snapshots of the intelligence layers | Planned |
| Audit-trail coverage beyond the security surface, covering decisions and overrides | In development |
| Engineering leader dashboard: bus-factor trends, ownership drift, decision-staleness curves, scheduled digests | In development |
The half of the roadmap that has nothing to do with procurement.
| Item | Status | Note |
|---|---|---|
| Interface-dispatch recall | Exploring | The measured ceiling on our call-graph recall. On syft, 44% of what we miss is dynamic dispatch alone and a further 39% is dispatch with a closure at one end. Nobody in the measured field has cleared it, at 6.5 possible targets per call site, and matching that recall naively means emitting six edges where one is right. |
| A sealed JavaScript / TypeScript retrieval corpus | In development | Built and half graded. The sealed half is unrun, and nothing from it is quoted anywhere until it is evaluated, once. |
| More compiler oracles for graph precision | Exploring | Go and TypeScript are done. C#, Java, Kotlin and C++ each need a toolchain and a working build per repository; Rust has the toolchain and no sound call-graph tool exists for it; Python, Ruby and PHP admit no oracle even in principle. The honest status is "probably not", not "planned". |
| Foresight | Waitlist | Learned models that rank where a fix goes, what a change forgot and which tests to update, with no LLM. Hosted and enterprise. FORESIGHT.md |
| Session intelligence harvesting | Planned | Architectural decisions surfaced from AI coding sessions and proposed to the team knowledge base, so knowledge generated during agent work does not evaporate when the session ends |
- An LLM-based PR reviewer. The PR bot makes zero model calls per review, and that is the product rather than a limitation: nothing to hallucinate, nothing to prompt-inject, and pushing the same diff twice produces the same review twice. CodeRabbit and Greptile do the other thing, and do it well. If you want intent-reading review, run one of those alongside this.
- Runtime or APM data. Everything here is derived from source and git history. A performance finding we report is a static one, and we label it as static.
- Any language behind a paywall. Stated above, repeated here because it is the question we get asked most.
- Dates. See the top of this page.
- Open an issue and say what you need and why. Demand is what moves an Exploring row to Planned, and we say so rather than implying the order is purely technical.
- Commercial and procurement timelines: hello@repowise.dev
- Security review: security@repowise.dev