乐趣区

关于sap:SAP-Spartacus的发布方式以及语义化版本管理机制

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 的原创文章,尽在:” 汪子熙 ”:

退出移动版