我们知道咱们目前在用的 Composable Storefront，基于 SAP Spartacus 这个开源项目，在 5.0 的时候，Spartacus 成为 SAP 正式产品之一，更名为 Composable Storefront. 咱们今天谈论的是 Composable Storefront 的升级问题，首先就要明确为什么我们要进行升级。
Spartacus 基于一系列的前端框架和第三方库，最显著的就是 Angular 这个开发框架和 Node.js。Angular 我们都很熟悉了，Spartacus 实际就是一个 Angular 应用，而 Node.js 的作用，主要体现在两个方面。一是 Spartacus 服务器端渲染基于 ngUniversal 这个工具库，而 ngUniversal 需要使用 Node.js 作为执行引擎。二是 Commerce Cloud Hosting Service 需要使用 Node.js 来对应用进行构建。
先看 Angular 本身的版本升级策略。Angular，Node.js 和 Spartacus，采取的都是语义化版本命名机制，A.B.C. A 代表 Major 版本也就是我们通常说的大版本，这些大版本的升级，包含大规模的功能更新，通常会引入不能向下兼容的 breaking change，不能向下兼容意味着旧版本的 Angular 应用，升级了大版本之后，需要开发人员手动修改源代码进行 rework，才能适配大版本升级后的 Angular 框架。
Angular 目前基本上每隔6个月就会发布一次新的大版本。
A.B.C 中间的 B 是 Minor 版本也叫小版本，理论上来说小规模的功能更新，不会对现有代码造成影响。底层框架的性能优化就经常放到小版本的更新里去。Angular 每个大版本内会包含1到3次小版本的更新。
Patch 版本包含错误修复。Angular 几乎每周都会发布一次新的 Patch 更新。
Angular 进行版本更新，原因主要有引入新功能，优化性能，提高开发者和终端用户使用体验，修复bug，安全漏洞等等。
我们从下面这张表里看到每个 Angular 的大版本会分为 Active 和 LTS 就是 Long Term Support 两个状态。Active 状态指这个版本处于积极的维护和小版本的迭代更新中，而 LTS 状态的版本，意味着这个版本已经非常稳定，不再进行新功能的迭代，而只包含非常 critical 的 bug 和安全漏洞的修复了。
简而言之，Active 状态的版本，小版本会继续迭代。而 LTS 状态的版本，只会有 patch 版本的更新。
Node.js 和 Angular 版本迭代的机制类似。
只是多了一个 CURRENT 状态，大家可以理解成开发版本，即 Node.js 发布给生态圈，搜集反馈并持续优化的版本。CURRENT 版本不建议用于生产环境。
Node.js 的每个版本都会从元素周期表里摘出一个元素作为版本代号。
比如 SAP 建议客户尽早升级到 Node 18，其维护状态结束日期是 2025年4月30日，还很早，而 Node.js 20 现在还是 CURRENT 状态，不建议在生产系统使用，所以我猜测 CCV2 目前也没有这个版本。
正因为 Angular 和 Node.js 每个版本都有着各自的生命周期，所以依赖于这两个工具的 Spartacus，每个版本也有着自己的生命周期。SAP 产品对于其使用的第三方库的版本有着严格要求，不允许使用那些已经停止维护的版本。比如我们看一下 Spartacus 5，5.0 是 2022年11月23日发版的，在这个时间点 Angular 12 早就已经过了维护日期，所以 Spartacus 5 不可能支持 Angular 12.
而 Angular
14 的维护结束日期是 2023年11月，也就是 Spartacus 5.0 发布一年之后。
再比如如今我们推荐客户升级到最新的 6.x 版本，依赖的 Angular 15，Node.js 18，分别在 2024年5月份和2025年才停止维护。
目前 Spartacus 每个小版本的有效时间是 6 个月。我们看一下 5.2 是2023年2月发布的，今年8月份结束了它的维护窗口。到目前为止，最新的是 6.4 版本，明年3月份结束维护。
推荐的升级路径是先从 5.2 升级到 6.0，再从 6.0 这个大版本开始往上升小版本。之所以要分成这两个阶段，原因之一是涉及到的 Angular 大版本的升级，和小版本的升级，执行的命令行是不一样的，没有办法一个命令行就一步到位。原因之二是这种先升级大版本，再升级小版本的分段步骤，如果升级过程中出现问题，更方便对问题进行隔离和定位，能够区分问题到底是大版本升级造成的，还是小版本升级造成的。
之前有客户反馈，大版本升级之后，之前定制开发里基于的一些 Angular 组件和服务，在升级之后找不到了，或者说发生了拆分，变成了多个。对于这种不能向下兼容的更改，一方面是以文字描述的方式，记录在了 SAP 官方帮助文档里。另外一种方式是，在 github 上能找到 Spartacus 的源代码，在源代码里根据关键字 //TODO: Spartacus 就能找到所有发生了不能向下兼容的代码的全部位置。另外，Spartacus 也提供了所谓的 migration schematics 即自动扫描机制来辅助大版本的升级。这个工具会扫描我们的二次开发代码，当发现代码里引用的组件或者服务，在大版本升级之后发生了不能向下兼容的更改，就会自动加上 TODO 的注释，以及包含了简单的更改建议。图里是一些例子。
