Versioning & Releases
How DirectoryLaunch releases are numbered, what a MAJOR, MINOR or PATCH bump means for your project, and how to read the changelog before you merge.
Every release is a semver git tag (v1.15.0) with a GitHub Release and a changelog entry.
Nothing ships to you automatically — you decide what to merge and when.
What a version bump means for you
| Bump | Example | What it costs you |
|---|---|---|
| PATCH | 1.14.0 → 1.14.1 | Nothing. Bug fixes, security fixes, dependency bumps. Always safe to take. |
| MINOR | 1.14.1 → 1.15.0 | A new feature or vertical. Safe merge. May add a config key, an env var, or an additive migration. |
| MAJOR | 1.x → 2.0.0 | Manual work. A config key was renamed or removed, a component API changed, or a migration is destructive. UPGRADING.md tells you exactly what to do. |
Security fixes ship as PATCH bumps precisely so you can take them without reading anything. If you only ever merge patches, do that.
Reading a changelog entry
Every bullet carries a tag:
[core]—lib/,app/api/,components/ui/,middleware.ts,supabase/. You almost certainly haven't edited these files, so they merge cleanly. Take our version.[ui]— marketing pages, layout components, styles. If you redesigned your site, these are the bullets that will conflict. Keep your version.
Each release also states the migrations it requires and any new env vars, so you know the full cost before you start:
## [1.13.0] - 2026-07-27
### Added
- `[core]` Get a Quote (RFQ) — visitors send quote requests to listing owners.
- `[ui]` Browse by city and state on a normalized location model.
**Migrations:** 0007_add_location_slugs.sql, 0008_add_quote_requests.sql
**New env vars:** noneYou get the same list, checked against your actual project, from pnpm upgrade:check.
Where to find releases
| Where | What it gives you |
|---|---|
| The public changelog | Human-readable, with screenshots |
CHANGELOG.md in your repo | The same history, offline, at the version you have |
UPGRADING.md in your repo | Manual steps for the releases that need them |
| GitHub Releases on the repo | Every tag, with notes, in one list |
git tag --sort=v:refname | The raw list, locally |
Which version am I on?
node -p "require('./package.json').version"pnpm upgrade:check prints it alongside the newest release available, so that's usually the
faster question to ask.
How releases are cut
Every change lands through a pull request that states whether it is core or ui, whether it
needs a config change or a migration, and which customer-editable files it touches. CI runs
lint, typecheck and build on every one. A release is tagged only from a green main, and
technical changes are kept in separate commits from visual ones — so you can take a bug fix
without taking a redesign.
Next: Updating the codebase.