Hello everyone! This blog post is aimed at any customers using SAP Commerce Cloud, Composable Storefront (also known as project “Spartacus”).
How we number releases is changing. Starting February 2024, we will stop using semantic versioning and instead align with Commerce Cloud numbering. The primary reason is to align with backend release versions, making it easier to understand that the frontend and backend releases are synchronized.
The number of times per year we update the Angular framework is also changing. We usually updated the Angular framework twice per year, but now we will do it once each year, in Q1.
Project “Spartacus” was first released in July of 2019 as an open source project (see the history). Each release of Spartacus was compatible with multiple Commerce Cloud backend update releases. To number our releases, semantic versioning (semver) has been used since 1.0 to indicate major, minor, and patch releases.
For example, in the old numbering, given the version number 6.5.4:
Starting November 2022, Commerce Cloud has moved to a continuous innovation model (see documentation). To better align with Commerce Cloud, we in Composable Storefront team want to:
For example, for a release in a particular month, if the backend is 2211.10, the Composable Storefront release would also be 2211.10.
Our current policy is to test the Composable Storefront release against the backend of the same month, plus prior releases less than 6 months old. (See the Composable Storefront update release policy and Commerce Cloud update releases pages.) We will sometimes publish patches, such as 2211.10.1, during a particular month, but only if really necessary.
Semantic versioning rules include the ability to use symbols in package.json files that indicate “take latest patch” (~) and “take latest minor” (^). Our recommendation to customers will be to use only ~ symbol or no symbols at all.
The primary reason for this change is to align with backend release versions and make it easier to understand that the frontend and backend releases are synchronized. Currently, we strongly recommend that customers use backend and frontend releases from the same month.
In parallel, we will share upcoming updates ahead of time about breaking changes so that customers are prepared for when it happens. For example, the update to the last Angular framework is scheduled for release in February as well.
The reasoning behind this change is that the communication of well-documented backwards-incompatible changes ahead of time is more important than the numbering itself, and syncing the versioning make it easier for everyone involved to understand what version to use. We also have received feedback that dev teams only use the ~ symbol in package.json files (take the latest patch only for builds), as it is really the safest way to work, or they use no symbols at all and are always specific about the version used.
Feedback welcome!
Bill Marcotte
Head of product, Composable Storefront / Spartacus and Frontend Technologies
SAP Industries and Customer Experience
How we number releases is changing. Starting February 2024, we will stop using semantic versioning and instead align with Commerce Cloud numbering. The primary reason is to align with backend release versions, making it easier to understand that the frontend and backend releases are synchronized.
The number of times per year we update the Angular framework is also changing. We usually updated the Angular framework twice per year, but now we will do it once each year, in Q1.
Background
Project “Spartacus” was first released in July of 2019 as an open source project (see the history). Each release of Spartacus was compatible with multiple Commerce Cloud backend update releases. To number our releases, semantic versioning (semver) has been used since 1.0 to indicate major, minor, and patch releases.
For example, in the old numbering, given the version number 6.5.4:
- Change the “6”, it’s a new major, with new features, but with changes that are not backwards compatible (for example, deprecated code is removed, or a feature's behavior changes)
- Change the “5”, it’s a new minor, with new features, but done in a way so that it is backwards compatible (features are disabled by default, no deprecated code removed)
- Change the “4”, it’s a bug fix that is backwards compatible.
What is going to change
Starting November 2022, Commerce Cloud has moved to a continuous innovation model (see documentation). To better align with Commerce Cloud, we in Composable Storefront team want to:
- Stop using semantic versioning
- Use the same version number of backend released in a particular month (2211.x)
For example, for a release in a particular month, if the backend is 2211.10, the Composable Storefront release would also be 2211.10.
Our current policy is to test the Composable Storefront release against the backend of the same month, plus prior releases less than 6 months old. (See the Composable Storefront update release policy and Commerce Cloud update releases pages.) We will sometimes publish patches, such as 2211.10.1, during a particular month, but only if really necessary.
Semantic versioning rules include the ability to use symbols in package.json files that indicate “take latest patch” (~) and “take latest minor” (^). Our recommendation to customers will be to use only ~ symbol or no symbols at all.
The primary reason for this change is to align with backend release versions and make it easier to understand that the frontend and backend releases are synchronized. Currently, we strongly recommend that customers use backend and frontend releases from the same month.
In parallel, we will share upcoming updates ahead of time about breaking changes so that customers are prepared for when it happens. For example, the update to the last Angular framework is scheduled for release in February as well.
The reasoning behind this change is that the communication of well-documented backwards-incompatible changes ahead of time is more important than the numbering itself, and syncing the versioning make it easier for everyone involved to understand what version to use. We also have received feedback that dev teams only use the ~ symbol in package.json files (take the latest patch only for builds), as it is really the safest way to work, or they use no symbols at all and are always specific about the version used.
Feedback welcome!
Bill Marcotte
Head of product, Composable Storefront / Spartacus and Frontend Technologies
SAP Industries and Customer Experience
- SAP Managed Tags:
1 Comment
