how to

Streamlining updates across free and paid software versions

the short answer

To ship updates to free and paid versions simultaneously, make 'an update' a single commit on one mainline and make editions a build parameter: each tier builds from the same commit with its own flag config. Then a security patch, a bugfix, or a shared feature reaches every edition the moment CI runs — no backports, no version skew.

When editions live on separate lines, they acquire separate version histories. The saas runs 2.4.1 while the community edition sits on 2.3.0 'until we backport'. Issues arrive against versions you barely remember; changelogs need an asterisk per edition; and security patches — the updates that least tolerate lag — wait on the slowest branch's release ritual.

Skew is also a trust problem for open-core products. An open-source repo visibly behind the hosted product reads as abandonware, even when the lag is pure process. The fix is to make 'an update' a single commit on one mainline and editions a build parameter.

90%of companies use open source in some form — when your free edition is open source, update lag between editions is publicly visible lag.Source: GitHub Octoverse Report, 2022
connect a repo →about tier·dev

One mainline, three release artifacts

The streamlined pipeline has a single shape: commit to main, CI builds once per tier with that tier's resolved flag config, every edition releases from the same SHA.

Shared fixes — the majority of all changes — need zero edition-specific work; they're in every artifact automatically. Tier-specific features merge to main dark, flagged off where they don't belong; enabling one later is a config diff, not a code release.

Version numbers stay unified: community 2.4.1 and saas 2.4.1 are the same code, configured differently. Support triage gets dramatically simpler.

Testing without doubling the suite

Run the full test suite once against the superset (all flags on), because that's where logic bugs live. Then add a thin per-tier contract suite that asserts wiring rather than logic: the open-source build boots with the pro dashboard absent, the saas build exposes billing endpoints, nothing more.

Contract suites stay a few dozen assertions because the matrix — not the test suite — is the source of truth for who-gets-what.

Release notes from the matrix

A quiet bonus: when edition differences are flag values, per-edition release notes generate themselves. 'New in saas this release' is the set of flags whose saas value flipped since the last tag, plus the shared changelog. tier·dev's matrix and generated config give you that diff for free — it's just the config file's git history.

how it works

  1. 01

    commit once to main

    Make every change — shared or edition-specific — a single commit on one mainline; never branch by edition.

  2. 02

    merge tier-specific work dark

    Land paid features flagged off where they don't belong; enabling one later is a config diff, not a code release.

  3. 03

    build per tier from the same SHA

    Have CI build once per tier with that tier's resolved flag config, so every edition releases from the same commit.

  4. 04

    test the superset, then the wiring

    Run the full suite against all-flags-on, then a thin per-tier contract suite that asserts flag wiring.

  5. 05

    patch security in one motion

    Patch main once, rebuild all tiers, release — no per-edition backport ritual.

frequently asked

What about updates to the paid tier we don't want public yet?
Merge them dark. The code ships flagged off in the open-source build (or stripped at build time if absence matters), and the announcement is a flag flip on your schedule, decoupled from the merge.
Do all editions have to release at the same cadence?
No — same commit pool, independent cadence. The saas can deploy main daily while the community edition tags monthly; the point is any tag works for every edition.
How do security patches flow?
Patch main once, rebuild all tiers, release. That 'one motion' property is the single strongest argument for the unified mainline.

Published June 6, 2026 · Last updated June 16, 2026

more on tier·dev

tier·dev — git-integrated feature flags for open-source + saas tiers →

ready to try tier·dev?

connect a repo →