> For the complete documentation index, see [llms.txt](https://docs.sylius.com/public/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sylius.com/public/open-source/release-cycle.md).
# Release Cycle
This document explains the **release cycle** of the Sylius project (i.e., the code & documentation hosted on the main `Sylius/Sylius` [repository](https://github.com/Sylius/Sylius)).
Sylius follows the [Semantic Versioning](https://semver.org/) strategy:
* A new Sylius patch version (e.g., 1.14.1, 1.14.2, etc.) usually comes out *every 3 to 6 weeks*, depending on the number of bug fixes developed
* A new Sylius minor version (e.g., 1.14, 2.1, 2.2, etc.) is released depending on various factors (see below), usually *every 3 to 6 months*
* A new Sylius major version (e.g,. 2.0, 3.0, etc.) is also released, depending on various factors, usually *every 2 years*
New Sylius minor releases will drop unsupported PHP versions.
### Scope-based vs time-based
The Sylius **release cycle** is **loosely** time-based (contrary to the [Symfony release cycle](https://symfony.com/releases)). Based on the experience from over 10 minor versions, we decided that time is not the only reason on which we should rely when planning the new Sylius version. Therefore, each new minor release of Sylius takes into consideration:
* What we would like to include in it (features, improvements, fixes)
* When we would like to release it (based on the Team capacity, estimated amount of work, and experience from previous minor releases development)
{% hint style="info" %}
The natural consequence of such a decision is uncertainty regarding the exact time of the next minor version release. We try to estimate it as precisely as possible, but sometimes delays cannot be avoided. We believe that releasing a **good** product is more important than releasing it **fast** 🤖
{% endhint %}
### Development
The full development period for any minor version is divided into two phases:
* **Development**: *The first 5/6 of the time is intended for the release* to add new features and to enhance existing ones.
* **Stabilization**: *The last 1/6 of the time intended for the release* is to fix bugs, prepare the release, and wait for the whole Sylius ecosystem (third-party libraries, plugins, and projects using Sylius) to catch up.
During both periods, any new feature can be reverted if it isn’t finished in time or isn’t stable enough to be included in the coming release.
### Maintenance
Each minor Sylius version is maintained for a fixed time after its release. This maintenance is divided into:
* *Bug fixes and security fixes*: During this period, all issues can be fixed. The end of this period is referenced as the ***end of maintenance*** of a release.
* *Security fixes only*: During this period, only security-related issues can be fixed. The end of this period is referenced as the ***end of support*** for a release.
### Planned releases
| Version | Development starts | Stabilization starts | Release date |
| ------- | ------------------ | -------------------- | ------------ |
| 2.3 | Q1 2026 | Q2 / Q3 2026 | Q2 / Q3 2026 |
### Supported versions
| Version | Release date | End of maintenance | End of support | Status |
|---|
| 2.2 | Dec 17, 2025 | September 2026 | March 2027 | Fully supported |
| 2.1 | Jun 4, 2025 | March 2026 | September 2026 | Security fixes only |
| 1.14 (LTS) | Nov 12, 2024 | December 2025 | December 2026 | Security fixes only |
### Unsupported versions
| Version | Release date | End of maintenance | End of support |
| ------- | ------------ | ------------------ | -------------- |
| 2.0 | Nov 12, 2024 | Aug 31, 2025 | Feb 28, 2026 |
| 1.13 | Apr 23, 2024 | Jan 31, 2025 | Apr 30, 2025 |
| 1.12 | Oct 31, 2022 | Jun 30, 2024 | Dec 31, 2024 |
| 1.11 | Feb 14, 2022 | Jan 31, 2023 | Oct 31, 2023 |
| 1.10 | Jun 29, 2021 | May 14, 2022 | Jan 14, 2023 |
| 1.9 | Mar 1, 2021 | Nov 1, 2021 | Jul 1, 2022 |
| 1.8 | Sep 14, 2020 | May 14, 2021 | Jan 14, 2022 |
| 1.7 | Mar 2, 2020 | Nov 16, 2020 | Jul 16, 2021 |
| 1.6 | Aug 29, 2019 | Apr 29, 2020 | Dec 29, 2020 |
| 1.5 | May 10, 2019 | Jan 10, 2020 | Sep 10, 2020 |
| 1.4 | Feb 4, 2019 | Oct 4, 2019 | Jun 4, 2020 |
| 1.3 | Oct 1, 2018 | Jun 1, 2019 | Feb 1, 2020 |
| 1.2 | Jun 13, 2018 | Feb 13, 2019 | Oct 13, 2019 |
| 1.1 | Feb 12, 2018 | Oct 12, 2018 | Jun 12, 2019 |
| 1.0 | Sep 13, 2017 | May 13, 2018 | Jan 13, 2019 |
### Backward Compatibility
All Sylius releases have to comply with our [Backward Compatibility Promise](broken://pages/ZbxcZJyZ9XyF5D3vzem0).
Whenever keeping backward compatibility is not possible, the feature, the enhancement, or the bug fix will be scheduled for the next major version.
***
### Pre-release Testing, Dependency Verification, and Security Assurance
Before every new release of Sylius (both patch, minor, and major versions), we execute a rigorous, automated validation pipeline to ensure that the software meets our standards for stability, compatibility, and security.
#### **Comprehensive Build Matrix**
Each release triggers a test matrix in our Continuous Integration (CI) environment that covers:
* All maintained Sylius packages (monorepo and split packages).
* All supported combinations of PHP and Symfony versions.
* Multiple permutations of optional or edge dependencies (e.g., different versions of Doctrine, API Platform, or Payum).
* Both production and development Composer flags (e.g., `prefer-stable`, `prefer-lowest`).
This ensures that the codebase is compatible across environments and that integrations between components (Admin, Shop, API, Core, Resource, Grid, etc.) function as expected.
#### **Security Advisory Checks**
We enforce security checks using [FriendsOfPHP/security-advisories](https://github.com/FriendsOfPHP/security-advisories?utm_source=chatgpt.com) – a widely trusted community-maintained database of known PHP vulnerabilities (CVE reports). This step verifies:
* That none of the currently installed Composer dependencies are affected by a published CVE.
* That the minimum and maximum version constraints defined in `composer.json` files only allow secure versions to be installed.
If a vulnerability is detected in a direct or transitive dependency, we block the release. Our process then includes:
1. Waiting for an upstream fix, and updating the dependency constraint to exclude vulnerable versions (via `conflict` or `>=` constraints).
2. Proactive contribution, where possible, to the affected project to accelerate the resolution.
3. Patch-based mitigation, in rare cases, where we apply a temporary workaround internally or isolate the vulnerable component.
#### **Continuous Verification**
Our pipelines also run scheduled builds on `main` and supported version branches to continuously monitor the security status and compatibility of the codebase, even outside of formal release cycles.
We monitor the release feeds of Symfony, PHP, and key dependencies to anticipate breaking changes or critical security releases early. This allows us to proactively plan compatibility updates, rather than reactively patching post-release.
#### **Release Lock and Governance**
Every release candidate must pass the full suite of:
* Unit and functional tests
* Behat integration scenarios (covering the Admin, Shop, API)
* Security validations
* Package publish dry runs (to test split package readiness)
* Upgrade and BC compliance checks
Only after these checks pass is a release approved and tagged publicly. This gatekeeping mechanism ensures that all published Sylius releases conform to enterprise-grade software lifecycle standards and can safely be used.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.sylius.com/public/open-source/release-cycle.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.