RELEASES

Every fix in this release was found by a machine walking between engines, not by a human reading code. The ring is a campaign that visits ordered pairs of engines — DuckDB to Postgres, Postgres to MySQL, DuckDB to Trino — and at each stop runs the entire command surface against real databases: flip the project onto the new engine, parse, seed, build twice, snapshot twice, check idempotence, reconcile row counts AND named values, generate docs, generate sources, generate base views, execute a native statement, retract everything, land a branch. Twenty-seven commands per hop. A hop is green only when all twenty-seven pass; anything less is a bug to fix, not a result to record. Sixteen hops are green so far, and they produced the fifty-odd fixes below — a silent row-duplication bug, a segfault that killed every Python model on macOS, a retract that deleted the project's own source tables, quoting that broke on seven engine-and-role combinations, and a bulk loader that landed different column names than the ordinary one. Most of these had passed every test suite DVT had.

The simplification release. Everything DVT runs on now lives in ONE environment — the per-engine private runtimes are gone, and with them the entire class of drift, provenance and missing-adapter failures they bred. Eighteen engines are supported out of one install: Postgres, Redshift, Snowflake, BigQuery, Athena, Databricks, DuckDB (and MotherDuck), Trino, ClickHouse, Oracle, SQL Server, Fabric, SQLite, StarRocks, Exasol, MySQL, MySQL 5.7 and MariaDB — every one validated against its real engine. dvt sync is now one install with a collision guard: it sets up the engine core, every adapter, your drivers and the Sling engine, self-heals a corrupted download, and removes conflicting packages with a stated reason. On top of the simpler engine room: seeds honor selection exactly as you'd expect — graph selectors included — --fail-fast stops a run at the first failure, the health surface guards every scaffolded setting in dvt_project.yml, and retract tells the truth about what it dropped, where it actually landed.

The write release. DVT has always read across every engine — now it writes across them too, through one battle-tested lane: dbt-compatible pre- and post-hooks on federated models (pre-hooks on SOURCE engines, post-hooks on targets — including pinned custom targets), dvt exec for one engine-native statement on any connection, an Explorer grid editor that previews the exact SQL before an explicit APPLY, and opt-in, key-gated DML endpoints on the api-portal. Underneath: every secret moved out of loose files into one machine store, the app suite always serves the project you launched it from, and a full audit closed every gap between the connection surface Settings advertises and what every lane actually honors — nothing connects silently wrong anymore, and nothing fails silently either.

The trust release. dvt config-checkup makes model configs tell the truth — the engine's own federation classification applied to your files, provable problems fixed automatically, ambiguous ones offered as choices (AI-chat style, in the terminal and in Martin's cards alike). flip-target-to runs it first, always. Settings learns every authentication method your adapters speak — keypair Snowflake included, on BOTH lanes — and gains a TEST CONNECTIONS button that probes every connection on both layers and shows you exactly what's healthy. Underneath: an Oracle federation milestone, visible execution paths, and one clock.

The default target stops being a commitment. dvt init scaffolds a project with a DuckDB warehouse out of the box — dvt build is green seconds after pip install, no warehouse account, no prompts — and dvt flip-target-to migrates the whole project to any engine's dialect in one deterministic command when you outgrow the laptop, with an AI rescue pass for the models determinism can't touch. Around that headline: generate-sources learns to read buckets, Martin delivers many charts in one answer and narrates his steps, Data Explorer joins the suite, and Dashboards grow folders, richer formatting, and chart types that know what your columns can express.

The agent leaves the browser: dvt martin puts the same Martin — same tools, same streaming work ledger, same APPLY gates — in your terminal. He also learns to manage the project itself (scheduled jobs, connection health, maintenance runs — never your credentials), generate-sources learns the whole profile in one sweep, and the DVT mark now sits in every app's topbar, one click from the hub.

A release forged in the trial fleet: every generate-sources failure reproduced against real engines and fixed at the root, four field bugs down (including one that silently hid bucket sources), sources.yml generation promoted to a first-class CLI command, DVT Dashboards live on :46108 fed by your saved chat assets, and Martin now streams his work as it happens — with automatic recovery when your gateway's model catalog shifts under him. Rolls up 0.2.34 and 0.2.35.

Meet Martin — DVT's data agent. Ask your project a question in English; Martin writes the SQL, DVT guards it and answers it live through federation. Chat with Martin ships on port 46104 with the whole suite: a code-verified expert corpus inside the wheel, a / palette over your actual models and sources, sessions that persist per project, canvas charts, and assets you save for the Dashboards to come. One AI outlet: AI-Proxy — your existing subscriptions or fully offline Ollama behind one gateway.

meta.connection goes on every source — including ones on the default target. The docs now say it in one voice everywhere, and the engine backs it up: a source without meta.connection gets a clear warning naming the fallback it triggered, and a failed resolution names the real cause instead of a generic 'output not found'.

Two scheduling modes: jobs can now be MANUAL ONLY — a saved dvt command with no cron at all, run when you need it — chosen with a schedule-mode flip right in the ADD JOB form. And the whole schedule gets a master ON/OFF: pause every cron firing without touching a single job definition; RUN NOW keeps working throughout.

The scheduler grows up: kill the whole suite but keep the schedule firing (dvt kill --exclude scheduler), stop any running job dead with a KILL button that takes its whole process tree, and read every run on a LOGS page that tells you what went well, what warned, and exactly what the error was — parsed from dvt's own output, with the full raw log one click away.

Two scheduler refinements: custom cron schedules become five labeled dropdowns — minute, hour, day, month, weekday, in plain words — and job history survives dvt kill. A run in flight when the suite goes down finishes on its own (kill spares running work), and the history now says exactly that instead of losing the record.

The first roadmap tile goes live: DVT Scheduler on :46106. Your dvt commands on a cron — nightly builds, hourly syncs, scheduled retracts — with per-run history, full logs, an overlap guard, and RUN NOW. Jobs are verb-whitelisted dvt commands executed directly (never a shell), and the whole thing arrives with dvt serve like the rest of the suite.

The Connections tab becomes a real credential manager: pick any of the 19 supported engines and buckets from a dropdown, get that adapter's own pre-filled form (filesystem gets a folder picker), and every finished connection lands as an editable card — add another, set the default target, delete with guardrails, then SYNC SOURCES. Full CRUD on profiles.yml, scoped to your project's profile, backup on every write, duplicates rejected. Plus AI-Proxy credentials get real fields.

The hub grows DVT Settings — one card, five tabs, everything about this machine and this project. Account and subscription with offline activation for air-gapped servers, machine specs framed as federation sizing, a profile-scoped connection manager that edits only your project's credentials with a backup on every write, AI keys for the features ahead, and a hosting map for network admins.

A small finishing cut on the suite's chrome: each app names itself — DATA CATALOG, API PORTAL — while the hub alone carries the full DATA VIRTUALIZATION TOOL brand. And the theme circle now holds the same far-right slot on every page, catalog included.

The suite starts feeling like one product: the hub, catalog and api-portal share a single top bar — logo far left at the same coordinates, one pill language for buttons, the theme circle always the far-right element. The catalog's search makes room for the same chrome, the ⌂ HUB back-link appears only when the hub is actually running, and the hub itself now shows the roadmap: six planned apps, one port each.

Light mode stops blinding: the hub, catalog and api-portal (and getdvt.net itself) move to a two-tone grey — the page on a darker whitish grey, panels on a brighter one, zero pure white anywhere, secondary text darkened for real contrast. Plus cohesive chrome: the theme switch sits at the far top right of every app, and the catalog gains a hub back-link like the portal's.

Column attribution goes scope-aware: pruning and pushdown now resolve per SELECT scope instead of one global alias map. Two UNION branches can read same-named tables on two different engines — unaliased — and each branch still prunes its columns and pushes its own filters. Plus a subtle correctness hardening the scope work surfaced: a table read twice in one model never gets one read's filter pushed into their shared extraction.

The extraction engine is rebuilt around syntax trees. Identifiers carry the model's own quoting end-to-end, every extraction renders once in its target dialect, and pushdown is now formally an optimization: anything a source engine can't express is simply computed in DuckDB instead — never an error, never approximated SQL shipped to an engine. Backed by a new transpilation-limits battery pinning the guarantees across ten dialects.

Federation models are written in DuckDB SQL — double quotes for identifiers, one dialect for every model — and DVT re-quotes everything per engine on the way out. This release closes the last gap in that promise: column names with spaces or true mixed case now survive the pruned extraction path on every engine, exactly as they already did in pushdown predicates.

dvt --version now tells you what you're actually connected to: every adapter your profile uses — including the ones living in dvt's isolated environments — with its version, and deliberately without upgrade nags: dvt owns those environments, so there's nothing for you to manage. Also, `dvt version` (the bare word) is gone; only the flag exists, exactly like dbt.

The api-portal sheds its cramped side drawer: every model gets a full page — columns, named endpoints, and a test console that runs APIs live and renders the rows as a data table. Plus the theme finally follows you: toggle light or dark once, and the hub, catalog and portal all agree.

The api-portal stops reading tables and starts virtualizing: every API call executes the model's logic live against its sources through the federation engine. Change a source row, the API answers differently — no dvt run. Plus named endpoints with locked row filters, dialect-correct identifier quoting, and a consumer console with snippets for four languages.

DVT grows a serving layer: switch any model on for REST consumption from a themed local portal — column-level access control, optional API keys, live queries against the model's own engine. Around it, the new DVT app suite on ports 46100–46109: one dvt serve starts the hub, the catalog, and the api-portal.

Every result line now carries its own story — rows inserted in green, coercion notes in yellow, no warning wall — and errors finally say what actually broke. Underneath: three engine fixes surfaced by real pipeline reshaping, and environments that heal their own Rosetta relics.

dvt kill grows into the one command you type when things feel stuck: catalogs come down, suspended runs (and the locks they hold) are reaped, and --force terminates running work deliberately.

Suspending a run doesn't kill it — it leaves a frozen process holding the federation cache lock, and the next run used to fail every model. DVT now detects the suspended run, reclaims the cache, warns you once, and carries on.

Protection by acceptance: a standard model that reads federated sources can never run through dbt alone — so DVT now runs it as federated, with a warning, instead of failing. The dag stays dbt's, the magic stays yours. Plus two extraction fixes the case exposed.

dvt retract is now the true mirror of dvt build — stored test failures come down with the models — and dvt run closes the last cross-connection escape hatch: standard materializations are refused foreign sources, not just foreign targets.

dvt retract grows up: dialect-correct drops on every engine, relations resolved exactly where the loader put them, bucket objects actually deleted, a --target override — and output that finally reads like dvt run.

A platform release: wheels for Python 3.13 and 3.14, Apple Silicon environments go native-arm64 only (Rosetta's days are numbered), and the catalog UI's light theme is rebuilt from the ground up as a true mirror of the dark one.

dvt version draws the actual DVT mark in full color (fastfetch-style), offline machine-bound licenses arrive, dvt retract returns by popular founder demand, dvt kill ends catalog-chasing, and the catalog UI gets a light theme.

Two foundations in one release. First: the dbt incremental experience, across engines — is_incremental() and {{ this }} now work in f_incremental models, your SQL owns the delta, and a tiny persisted index replaces full source replicas. Second: every dbt adapter now runs in its own isolated environment with its own dbt-core version — adapter version conflicts are structurally extinct. (0.2.6 was an internal milestone; all of its environment-isolation work ships here.)

The biggest performance release yet — homogeneous federated models now skip DuckDB entirely and stream source → target in a single hop — plus the new short materialization names, a hard guard against silently misrouted models, and an ASCII banner you'll actually want to run.

dvt seed grows into the simplest bulk loader you'll use: every Sling format, any target including buckets, and column names that behave identically on every engine.

dvt docs builds one catalog and one lineage graph across every engine in your project — and DVT's execution output becomes byte-for-byte dbt-style.

The federation pipeline becomes production-grade: parallel-safe caching, correct connection handling for the tricky engines, and incremental federation that holds up.

The first release of DVT as a wrapper around stock dbt-core: dbt runs everything it can, DVT federates the rest. No fork, no patched internals — dbt compatibility by construction.