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, with a maximum lead time of 20 workdays / 28 calendar days
- Critical and high‑severity bugs are released as soon as possible in a patch of the latest minor
Bug fixes may also be released on any active milestone branch when warranted.
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 |
| Pre‑release | 10.2.0‑beta | Preview or experimental features; APIs may change | Not production‑ready |
Release rings for DynamicWeb 10
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.
DW10 follows a versionless deployment model with monthly milestones delivered to release rings under a first‑in‑first‑out principle.
| 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
Starting in Q2 2025, DynamicWeb introduced Release Ring 0 as 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.
Features remain in Ring 0 for at least 30 days before becoming eligible for promotion to Rings 1–4. During this time, 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 existing bug-fix policy.
This has the following implications:
- Stability first: Rings 1–4 become more predictable and production-ready
- Longer ramp-up: New features will not be present in production until they’ve passed the one-month Ring 0 soak
- Trade-off: Faster feedback loops for developers, but a deliberate delay before features reach customers
Please note that critical security fixes are applied to milestones released within the past 12 months, regardless of ring
Supported versions by product
DynamicWeb Commerce Suite (DW10)
DW10 follows a versionless deployment model with monthly milestones delivered to release rings under a first-in, first-out principle.
- Rings 0–4: Every new milestone starts in Ring 0 and gradually moves through Rings 1–4, with stability increasing at each step
- 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 immediately on the latest milestone. Depending on urgency, they 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