streamlining updates across free and paid software versions
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.
the failure mode: 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.
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.
see this on your own repo
tier·dev turns the open-source / saas difference into per-tier feature flags — one repo, generated config, no sdk.
faq
- 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.