Release Policy
Guidance on DynamicWeb release cadence, support windows, and recommended versions for production environments
Production guideline
For production‑critical solutions, always deploy on release rings R3 or R4. Rings R1 and R2 move quickly and may contain unverified changes; they are recommended only for development, testing, or staging.
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
Release cadence
DynamicWeb works in two‑week sprints starting every other Wednesday. At the end of every second sprint—the last Tuesday of each month, except July—we cut a new minor version.
- Bugs logged in a given sprint are targeted for resolution within that sprint or the next one. The maximum lead time is therefore 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 — some rings get the newest features right away, others only get changes that are tested and stable
- Let you choose the right balance for your solution depending on its maturity and criticality.
And of course the main advantage; you catch bugs early without putting products at risk.
Note
Ring 0: Prerelease channel
Starting Q2 2025, DynamicWeb introduces 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.
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
Change log
- 2025‑07‑09: Clarified production recommendation (R3/R4) and risk of R1/R2; streamlined terminology tables; added FAQ section.