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的原创文章，尽在："汪子熙":