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官方路线图网站上的声明。
