SGEN platform governance
Release gates · breaking-change policy · deprecation · what operators can rely on
SGEN updates the platform without requiring operator action most of the time.
That is by design — Immutable Stability means the platform carries its own upgrade path.
But operators still need to know what SGEN commits to: what changes are treated as breaking, how those are communicated, what the deprecation runway looks like, and what the escalation path is when something changes unexpectedly.
This page documents those commitments.
What is this for?
Use this page when:
- A client asks what the notice period is before a feature changes behavior.
- You are evaluating whether a SGEN feature is safe to build a business process around.
- You need to explain to a developer why SGEN's update model is different from a self-hosted stack.
- You received a deprecation notice and want to understand the timeline.
- You are auditing a site after a platform update and need to know what changed.
Good use cases
Scenario 1: A client is automating order processing against the SGEN API and wants to know when API response shapes change.
API response shape changes are classified as breaking changes.
Breaking changes carry a 90-day runway before removal.
The Changelog publishes the breaking change notice on the day it enters the runway.
The client has 90 days from that date to update their integration.
**Scenario 2: You built a custom code snippet that targets a CSS class in the admin.
The admin redesign removed that class.**
Internal admin UI classes are not part of the public API contract.
They carry no guaranteed stability.
Custom code targeting internal admin classes breaks without notice.
Custom code targeting the public site's rendered HTML carries a shorter but still communicated runway.
Scenario 3: You are evaluating whether to store custom data in Custom Objects vs a separate database.
Custom Objects are a first-party SG-Core feature.
First-party core features carry the full stability commitment.
External databases you own are outside SGEN's governance entirely.
Scenario 4: The SEO Module's default sitemap behavior changed in an update and your client's ranking dropped.
Changes to default behavior — even for optional modules — are flagged in the Changelog as behavior changes.
If the change affected ranking, that is a support escalation: SGEN Support.
If the change was not announced in the Changelog, it is a bug.
Scenario 5: A feature you depend on is listed as deprecated in the Changelog.
Deprecated features remain functional for the full deprecation runway.
Check the Changelog entry for the sunset date and the recommended replacement.
Plan the migration to the replacement before the sunset date.
Deprecated features are not removed without a prior Changelog entry that includes the sunset date.
What NOT to use this for
This page describes the governance model — the rules and commitments.
It does not list every feature that has ever changed or been deprecated.
For that, read the Changelog.
This page does not describe SGEN's SLA (uptime, response time, incident response).
SLA details are in your subscription agreement.
For operational reliability architecture (how SGEN maintains uptime), see Performance and Reliability.
This page does not describe the SGEN roadmap.
Roadmap is in the Roadmap section.
How this connects to other features
- Changelog — The primary output of governance. Every release, breaking change, deprecation, and behavioral delta is logged here. View the Changelog.
- Performance and Reliability — The SLA-adjacent commitment about uptime and availability. See Performance and Reliability.
- Platform Values — The principles that govern what SGEN builds and how. See Platform Values.
- Naming Conventions — Governance includes naming stability. Feature names do not change without announcement. See Naming Conventions.
Before you start
No setup required.
Governance is a platform-level commitment; it applies to all SGEN operators.
This page is informational.
If you received a specific deprecation notice and need to take action, the notice itself contains the relevant links.
Where to find it
docs.sgen.com → Reference → Platform Overview → SGEN Platform Governance Overview.
Reference shape — release categories
1. Additive releases (most common)
New features, new options, new modules.
No existing behavior changes.
No operator action required.
These ship when ready.
They appear in the Changelog with the tag [NEW].
Additive releases do not trigger a notification by default — they are in the Changelog to discover.
2. Behavior changes
An existing feature behaves differently than it did before.
Not a new option — a change to what an existing option does.
Behavior changes ship after the Changelog entry is published.
The Changelog entry is published before the behavior change ships (minimum 7 days for low-impact changes, 30 days for significant changes).
Operators who subscribe to Changelog notifications see these before the change lands.
Behavior changes appear in the Changelog with the tag [CHANGED].
3. Breaking changes
A change that removes or alters an interface that operators depend on.
Breaking changes include:
- Removal of a previously documented API endpoint or response field.
- Removal of a previously documented admin feature.
- Change to a slug or identifier that scripts or integrations reference.
- Change to a data format that downstream integrations consume.
Breaking changes appear in the Changelog with the tag [BREAKING].
4. Deprecation notices
A feature is being retired.
It continues to work.
Operators should migrate to the replacement during the runway.
Deprecations carry a 180-day runway (minimum).
If no replacement exists yet, the deprecation notice is not published until the replacement is available.
The exception: features with known security risk are deprecated immediately and sunset on a security-determined timeline.
Deprecated features appear in the Changelog with the tag [DEPRECATED].
5. Security patches
Patches for vulnerabilities are shipped without runway.
They ship when ready.
If the patch changes observable behavior, a post-ship Changelog entry is published with a note explaining the security context.
Operators do not receive advance notice of security patches.
6. Hotfixes
Fixes for platform bugs that cause data loss, incorrect output, or service disruption.
Hotfixes ship without runway.
A Changelog entry is published after the fix ships.
Steps
1. Subscribe to Changelog notifications
The Changelog is the authoritative source for all governance events.
Subscribe via the RSS feed at docs.sgen.com/changelog.rss.
Or follow the Changelog page directly.
Filter by the [BREAKING] and [DEPRECATED] tags to reduce noise.
2. Read the Changelog before any major site build or automation
Before committing a workflow to a SGEN feature, check the Changelog for recent entries tagged [CHANGED] or [DEPRECATED] for that feature.
A recent change may affect your plan.
3. Respond to [BREAKING] notices within the runway
When you see a [BREAKING] entry:
- Note the sunset date.
- Identify which of your sites, scripts, or integrations uses the affected feature or interface.
- Plan and execute the migration before the sunset date.
- The Changelog entry includes the replacement or workaround.
4. Respond to [DEPRECATED] notices
When you see a [DEPRECATED] entry:
- Note the sunset date (minimum 180 days from notice).
- Identify which of your workflows uses the deprecated feature.
- Migrate to the replacement during the runway.
- Do not defer until the sunset date — the replacement may need configuration.
5. Check behavior after a platform update
After a platform update, check the Changelog entries tagged [CHANGED] for the release.
Review the entries that affect features your sites actively use.
If a behavior change produces an unexpected result, check the Changelog entry to confirm whether the behavior is intentional or a bug.
If it is a bug, file a support ticket.
Verification
After reading this page, you should be able to:
- Distinguish between additive releases, behavior changes, breaking changes, and deprecation notices.
- State the runway for breaking changes (90 days) and deprecations (180 days).
- Identify where SGEN publishes all governance events (the Changelog).
- Know what to do when a
[BREAKING]notice appears before the sunset date. - Know what operator action security patches do and do not require.
Technical details — what is and is not under the governance commitment
Under governance commitment:
| Surface | Commitment |
|---|---|
| Documented public API endpoints | 90-day breaking-change runway |
| Documented API response field names | 90-day runway |
| Admin feature labels and behavior | 30-day behavior-change notice |
| Custom Field schema shapes | 90-day runway |
| Module configuration options | 30-day behavior-change notice |
| Documented slug formats (page, post, custom object) | 90-day runway |
| SG-Builder component interface (component names, attribute keys) | 30-day behavior-change notice |
| Surface | Reason |
|---|---|
| Internal admin CSS class names | Not a public API |
| Admin HTML structure | Not a public API |
| Undocumented API endpoints or fields | Not committed to |
| Developer-mode or experimental features | Flagged as experimental in the docs — no runway guarantee |
| Third-party integration behavior (Stripe, Google) | Owned by the third party |
Notes
Note: "Immutable Stability" is a SGEN design principle.
It means the platform manages its own updates.
Operators do not run update commands, apply patches, or manage plugin compatibility.
SGEN carries the upgrade path.
This is the reason the governance commitments can be made cleanly — there is no "you need to update before the deprecation ships" step.
The platform updates itself.
The runway is for your integrations and workflows, not for applying platform updates.
Note: breaking changes are rare.
The dominant pattern in SGEN releases is additive.
The breaking-change runway exists as a commitment, not as an expected regular event.
In practice, most Changelog entries are [NEW] or [CHANGED] with behavioral impact scoped to a specific configuration state.
Note: the SGEN roadmap is not governance.
The roadmap describes what SGEN plans to build.
Plans change.
Governance applies to what has shipped and is documented.
Do not treat a roadmap item as a commitment.
Frequently asked questions about SGEN governance
Q: How do I get notified about breaking changes before they ship?
A: Subscribe to the Changelog RSS feed at docs.sgen.com/changelog.rss.
Breaking changes are tagged [BREAKING] and published at least 90 days before the sunset date.
You can also bookmark the Changelog page and check it before any major project or integration build.
Q: If a feature is in "experimental" state in the admin, does the governance commitment apply?
A: No.
Experimental features are explicitly outside the governance commitment.
They will be labeled "Experimental" or "Beta" in the admin and in the docs.
Do not build production workflows against experimental features.
When an experimental feature graduates to stable, it receives a Changelog entry and enters the full governance commitment.
Q: What happens if SGEN ships a breaking change without the 90-day runway?
A: That is a governance failure.
If you experience a breaking change without the runway, report it to SGEN support.
The remedy may include reverting the change, extending a compatibility shim, or accelerating your migration with direct support.
Q: Does the 90-day runway apply to security patches?
A: No.
Security patches ship without runway.
The runway applies to planned breaking changes, not to emergency security remediation.
If a security patch introduces a breaking change to the API or feature behavior, SGEN documents the breakage in a post-ship Changelog entry and provides remediation guidance.
Q: Can SGEN extend the runway for a breaking change if an operator needs more time?
A: In some cases, yes — contact SGEN support before the sunset date.
SGEN does not guarantee runway extensions, but operators in complex migration situations can request them.
Extensions are not automatic.
Q: How do I know if a behavior change affects my specific site configuration?
A: Read the Changelog [CHANGED] entry.
Each entry specifies the scope of the change: which feature, which configuration state, and what the previous and new behavior are.
If your site does not use the feature in the configuration state described, the change does not affect you.
If it does, the entry will include what to check and whether any action is needed.
Q: What is the governance treatment for module settings that control public-facing behavior?
A: Module settings are covered by the 30-day behavior-change notice.
This includes changes to default behavior, new options that override previous defaults, and settings that are removed or merged.
Settings that control outputs visible on the public site (sitemap URLs, consent banner text, redirect behavior) follow the 30-day notice rule.
Release communication channels
| Channel | What it carries | Where |
|---|---|---|
| Changelog | All releases: new, changed, breaking, deprecated | docs.sgen.com/changelog |
| Changelog RSS | Machine-readable Changelog feed | docs.sgen.com/changelog.rss |
| SGEN Status page | Uptime, incidents, maintenance windows | status.sgen.com |
| SGEN Support | Upgrade questions, runway extension requests, security disclosures | Contact via SG-Dashboard |