Spartacus 打包之后，以库的形式公布到 npmjs.com 上。
Spartacus 库次要有三个实体组成：core，Storefront 和 styles. 其中 Storefront 蕴含了用户肉眼可见的，组成 Storefront 外观的 UI 组件，客户能够重用和加强这些组件。Core 则蕴含了 Spartacus 的管制逻辑，用户通过 Angular 依赖注入的机制，能够开发本人的服务类，而后注入到 core 框架之中。Styles 蕴含了 Spartacus 的界面款式实现，客户能够对这些款式进行定制化，或者用自开发的款式来笼罩规范款式。
以前 Accelerator 同 Storefront 的比拟时曾经提到过，客户基于 Spartacus 库文件进行属于本人的 Storefront 开发，并不会间接批改 Spartacus 公布的源代码。客户的二次开发代码，和 Spartacus 库文件是一种松耦合关系。客户降级 Spartacus 版本，在绝大多数状况下都不会影响到当初的二次开发代码。那么所说的“绝大多数状况下”，具体是指什么呢？这就要从 Spartacus 的版本管理机制说起。
同绝大多数风行的框架和库一样，Spartacus 的版本治理也采取了所谓语义化版本的机制，版本号由主版本号，次版本号和订正版本号独特组成，两头由小数点分隔开。
主版本号的升高，用于引入无奈向后兼容的变更或颠覆性的更新。无奈向后兼容的变更，是指 Spartacus 降级之后，之前基于低版本编写的二次开发代码，须要人工调整后能力持续工作。颠覆性的更新，比方 Spartacus 3.0，首次反对 B2B 个性。
次版本的减少：用于引入新性能，并且版本更新之后，已有的二次开发代码不需任何调整依然可能失常工作。源代码重构，性能优化等不属于 bug 修复的批改，也通过此版本号引入。
订正版本：次要用于公布 bug 的修复.
Spartacus 的订正版本公布以周为单位，确保应用过程中发现的 bug 能尽早失去解决。次版本的升高以月为单位，而主版本的更新，能够参考 SAP 官网路线图网站上的申明。
更多 Jerry 的原创文章，尽在：” 汪子熙 ”: