Release Cycle
This document explains the release cycle of the Sylius project (i.e., the code & documentation hosted on the main Sylius/Sylius repository).
Sylius follows the Semantic Versioning 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). 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)
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
2.2
September 2025
Q4 2025
Q4 2025
Supported versions
2.1
Jun 4, 2025
March 2026
September 2026
Fully supported
2.0
Nov 12, 2024
August 2025
February 2026
Security fixes only
1.14 (LTS)
Nov 12, 2024
December 2025
December 2026
Fully supported
Unsupported versions
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.
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 – 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.jsonfiles 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:
Waiting for an upstream fix, and updating the dependency constraint to exclude vulnerable versions (via
conflictor>=constraints).Proactive contribution, where possible, to the affected project to accelerate the resolution.
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.
Last updated
Was this helpful?