Use this page when you need the policy details behind DynamicWeb release planning, production deployment, and support coverage.
This document explains how DynamicWeb ships software, the stability expectations for each release type, and the support windows that apply to our products:
- DynamicWeb Commerce Suite (DynamicWeb 10)
- DynamicWeb All‑In‑One Business Platform (DynamicWeb 9)
- DynamicWeb Swift
- DynamicWeb Addons
If you need the section overview or the standard month-by-month minor release calendar, start on the Releases landing page.
Release cadence
DynamicWeb works in two-week sprints starting every other Wednesday. At the end of every second sprint, on the last Tuesday of each month except July and December, we cut a new minor version.
The standard release cadence is:
- Bugs logged in a given sprint are targeted for resolution within that sprint or the next one, following the severity-based SLOs in the bug-fix policy
- Critical and high-severity bugs are released as soon as possible as a hotfix patch of the latest minor, ahead of the normal monthly cadence
Release terminology
| Release type | Example | What it may include | Intended impact |
|---|---|---|---|
| Major | 10.0 | Breaking changes, API removals, UX overhauls, or fundamental feature shifts | Upgrade planning and possible migration work required |
| Minor | 10.1 | New features, enhancements, support for new platforms or dependencies | Backward-compatible; low-risk adoption |
| Patch | 10.1.1 | Bug fixes, performance or stability improvements | Safe to adopt quickly |
Preview/experimental builds are not shipped as separate pre-release tags. New features become available in Ring 0 during their 30-day soak before flowing into the other rings — see Release rings below.
Compatibility and upgrades within a major
DynamicWeb is designed so that minor and patch releases within a major version can be adopted without rewriting custom code. This section describes what we commit to, where the limits are, and how to validate an upgrade safely.
Public API compatibility
Within a major version, the public .NET API is kept source and binary compatible. In practice this means:
- Existing customizations that compile against e.g.
Dynamicweb.Suite 10.xcontinue to compile and load against any later10.y - Public types, members, and signatures are not removed or changed in breaking ways inside a major
- Compatibility is verified automatically as part of our build using the .NET API compatibility check. If a breaking change slips through, we treat it as a bug and address it according to the bug-fix policy
- Breaking API changes are reserved for major releases (for example, the move from DynamicWeb 10 to a future DynamicWeb 11) and are documented in a dedicated upgrade guide
Behavior changes vs. regressions
Not every change is visible in the API surface. A release may also adjust how existing APIs behave:
- Unintended behavior changes are treated as regressions. They are reported, classified, and fixed under the bug-fix policy
- Intentional behavior changes — for example, correcting a bug where the previous behavior was wrong — are called out in the Changelogs so that integrators can review them before promoting a milestone to production
- In rare cases, a bug fix corrects faulty behavior that custom code has come to rely on. The fix still ships, the change is noted in the release notes, and the customization needs to be updated to match the corrected behavior. This is uncommon, and the release rings give you time to detect it before it reaches production
Impact on custom code
How smoothly an upgrade goes depends largely on how customizations were built. To stay on the safe side of the compatibility promise:
- Use the documented extensibility points — notification subscribers, providers, data integration adapters, the public service APIs, template tags, and the documented integration interfaces
- Avoid fragile patterns that sit outside the compatibility contract:
- Reflection into internal or private types and members
- Direct SQL writes against DynamicWeb-owned tables (read access for reporting is fine; mutation should go through the API)
- Copy/paste of internal source code into customer projects
- Depending on undocumented behavior or side effects of internal classes
- Customizations that follow the documented extensibility model typically pick up new minors with only a package version bump and a rebuild. Customizations that rely on the fragile patterns above can break on any release, including a patch, and are outside what the compatibility promise covers
.NET LTS updates within a major
DynamicWeb tracks Microsoft's .NET Long-Term Support (LTS) schedule so that solutions stay on a supported runtime throughout the lifetime of a major. Two precedents inside DynamicWeb 10 illustrate how this is handled:
- .NET 7 → .NET 8 between DynamicWeb 10 and 10.1 — a one-step move tied to a specific minor, documented in Upgrading from DW10 to DW10.1
- .NET 8 → .NET 10 during the DynamicWeb 10 lifetime — delivered via multi-targeted NuGet packages that support both runtimes in parallel, with an opt-in rollout per release ring and a generous overlap window before .NET 8 reaches end-of-support. See DynamicWeb 10 moving to .NET 10 for the full upgrade guide, runtime selection, and cloud rollout schedule
What this means for customer projects:
- The API compatibility promise still applies — DynamicWeb APIs remain stable across the runtime change, and most custom code only needs a rebuild
- When DynamicWeb packages multi-target two runtimes, customers can plan the runtime upgrade independently of taking new DynamicWeb minors, and switch when it fits the solution roadmap
- The change is always announced ahead of the release, with an end-of-support date for the older runtime
- Customer projects update their
global.json, target framework, and package references to the new .NET LTS as part of the move - Addons (integration framework, payment, shipping, etc.) are rebuilt against the new LTS and must be updated in lockstep via the appstore
The .NET LTS bump is the only category of change inside a major that requires planned developer work even for well-written customizations — and even then, only at the runtime/SDK and package-reference level.
Validating an upgrade with release rings
The release rings below are the supported way to verify a new milestone against your solution before it reaches production. A typical enterprise upgrade flow:
- R0 / R1 — point a developer or QA environment at the upcoming milestone. Build custom code, run the test suite, exercise integrations, and review any intentional behavior changes called out in the Changelogs
- R2 — run the staging environment for at least one full sprint. Use this window for UAT, integration soak, and load testing against representative data
- R3 / R4 — promote production once the milestone has cleared staging. R3 and R4 only receive critical fixes, so production stays predictable
This pipeline turns the compatibility promise into something verifiable on your own solution, rather than something you have to take on faith.
Release rings for DynamicWeb 10
DynamicWeb 10 follows a versionless deployment model: customers do not pin to a specific version number. Instead, each solution is assigned to a release ring, and the platform that ring points at advances automatically as new monthly milestones flow through the pipeline. This means upgrades happen in controlled, predictable steps rather than as standalone migration projects.
Release rings are stages that new software goes through before it reaches production. Think of them as checkpoints in a relay race: features start early where change is fast, and only move forward once they prove stable. Milestones move through the rings under a first-in, first-out principle — a new milestone enters Ring 0 each month, and every other ring shifts one position.
| Ring | Milestone | Stability | Bug-fix policy | Recommended use | Best fit use case |
|---|---|---|---|---|---|
| R0 | Current | Experimental | Continuous (features + fixes) | Demo/Test/Local Dev | Safe place to try the newest features and validate integrations before they move forward |
| R1 | Current | Fast-moving | Continuous | Development/QA | Active project development where you want features and fixes as soon as they’re ready |
| R2 | Current + 1 | Semi-stable | Weekly | Testing/Staging | Pre-launch staging, customer demos, or final integration testing with fewer surprises |
| R3 | Current + 2 | Stable | Critical fixes only | Production | Production systems needing reliability with low risk of disruption |
| R4 | Current + 3 | Stable | Critical fixes only | Production | Business-critical production with maximum stability and predictability |
In short, release rings:
- Control how quickly changes move into different environments
- Balance speed vs. safety because some rings get the newest features right away, while others only get changes that are tested and stable
- Let you choose the right balance for your solution depending on its maturity and criticality
The main advantage is that you catch bugs early without putting production systems at risk.
Note
Ring 0: Prerelease channel
Ring 0 is the earliest stage in the release pipeline. It contains all new features immediately after development and is available only in demo environments, test environments, and local developer installations — never production.
Features stay in Ring 0 for at least 30 days before becoming eligible for promotion to Rings 1–4. During this soak, developers and testers can validate integrations, uncover edge cases, and provide feedback. Bug fixes may flow more quickly into Ring 1 or Ring 2 according to the bug-fix policy.
The effect of this model is that Rings 1–4 stay predictable and production-ready, at the cost of a deliberate one-month delay before new features reach customer environments.
Critical security fixes are applied to milestones released within the past 12 months regardless of ring — see Supported versions by product below.
Supported versions by product
DynamicWeb Commerce Suite (DW10)
Because DW10 uses release rings, "supported" depends on which ring a milestone currently sits in and how recently it was released.
Tip
Is my DW10 version supported?
- If your milestone is still in Rings 0–4, it receives normal bug fixes as it moves through the pipeline
- If your milestone has dropped out of Ring 4, it no longer receives bug fixes or hotfixes — but critical security fixes still apply for up to 12 months after its original release
- Once a future major (e.g. DynamicWeb 11) ships, DynamicWeb 10 as a whole enters a 5-year support tail (3 years of bug fixes, then 2 years of security-only fixes). See Long-term support after a new major release below
What flows where, in detail:
- Bug fixes: Normal bug fixes travel with the milestone as it moves through the rings. When a milestone leaves the pipeline, it is no longer eligible for bug fixes
- Hotfixes: Critical or high-severity issues are patched on the latest milestone as soon as possible, ahead of the normal monthly cadence. Depending on urgency, the fix may be merged into Ring 1 first or directly into Ring 2
- Security fixes: Security patches are back-ported to any milestone released within the past 12 months, regardless of its current ring
Example with five minors
Imagine these consecutive minors: 10.8, 10.9, 10.10, 10.11, 10.12
- Month 0: 10.12 enters Ring 0
- Month 1: 10.12 moves to R1, 10.11 to R2, 10.10 to R3, 10.9 to R4
- Month 2: 10.12 to R2, 10.11 to R3, 10.10 to R4 → 10.9 leaves the pipeline
Once 10.9 drops out of Ring 4, it is no longer supported. That means:
- No new bug fixes will ever reach 10.9
- No hotfixes will be merged into it
- Only security fixes, if still within the 12-month back-port window, may apply
This ensures that all supported rings remain current and maintainable, while older milestones naturally phase out of the support lifecycle.
Long-term support after a new major release
When a new major version of DynamicWeb is released, such as DynamicWeb 11, the previous major enters a defined and predictable support lifecycle. This balances innovation with long-term operational stability.
The support timeline after a new major release is:
- Bug fixes: The previous major, for example DynamicWeb 10, continues to receive bug fixes for 3 years
- New features: The previous major does not receive new features after the next major is released
- Security fixes: After bug-fix support ends, security fixes continue for an additional 2 years
- Total support period: The previous major remains supported for 5 years from the release date of the new major
After the full 5-year period:
- No further bug fixes or security updates are provided
- Customers are expected to have planned and executed an upgrade to a supported major
In practice, this means:
- Customers have multiple years of overlap to plan, budget, and execute an upgrade
- Existing solutions remain safe and compliant long after a new major ships
- Innovation can move forward without forcing immediate migrations
DynamicWeb All‑In‑One Business Platform (DW9)
- Minor cycle: Twice a year (last Tuesday in January and August)
- Active support: Latest two minors (e.g. 9.17 and 9.18)
- Patch cadence: Every two weeks on Tuesday
- Security back‑ports: Minors released in the past three years
DynamicWeb Swift
- Minor cycle: Every 1‑2 months
- Active support: Latest minor only
- Patch cadence: Approximately every two weeks on Tuesday (fixes may appear earlier on GitHub “main”)
- Security back‑ports: Minors released in the past 12 months
DynamicWeb Addons
Addons include BC/NAV code units, DynamicWeb Live Integration, payment gateways, delivery providers, the DynamicWeb CLI, and similar components.
- Active support: Latest minor
- Patch cadence: Continuous, as issues are resolved