为何 Angular 4 是 Angular 2 的下一个版本, 为什么没有 Angular 3.x

发布时间:2019-06-08 发布网站:脚本宝典
脚本宝典收集整理的这篇文章主要介绍了为何 Angular 4 是 Angular 2 的下一个版本, 为什么没有 Angular 3.x脚本宝典觉得挺不错的,现在分享给大家,也给大家做个参考。

很多人看到 Angular2.4.x 版本之后直接跳到了Angular 4.0.0 beta 版本, 为什么没有 Angular 3.x 呢?

先说一下 Angular 4 将于 2017年3月 发布. (/≧▽≦)/

原因简单

原因并没有你想的那么复杂, 一句话就能描述:
__Angular开始使用SEMver语义化版本, 并做了一次版本对齐__.

早在去年9月. Angular 团队就宣布将使用 Semantic Versioning 也就是SEMVER.

语义化版本就像它的名字所说的一样, 让每一个版本号的添加都有其意义. 这可以让开发人员迅速明白此次升级的变动情况, 而且可以让第三方工具比如 NPM 可以更便捷更安全的进行操作.

一个语义版本包括三个数字:

主版本号 次版本号 修订号
破坏性变更 功能添加,无破坏性变更 Bug修正,无破坏性变更

版本号递增规则如下:

  1. 主版本号:当你做了不兼容的 API 修改,

  2. 次版本号:当你做了向下兼容的功能性新增,

  3. 修订号:当你做了向下兼容的问题修正.

先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面, 作为延伸.

SEMVER 详细文档可以参照此链接

那么这对Angular团队意味着什么呢? 就像每个不断发展的软件一样, 总会发生一些破坏性的改变. 例如, 现有应用程序报出了一个编译器错误, 这些错误在以前的编译器版本中未被注意到, 无论怎样这些错误将会在升级时破坏现有Angular应用程序, 这都需要团队变更主版本号.

就像以前 Igor Minar 说的, 即使只是将 Angular 的 TyPEScript 依赖 从 v1.8 升级到 v2.1 或者 v2.2 然后编译 Angular 也会在技上导致突破性的变化. 所以他们非常重视SEMVER.

破坏性的改变并不一定是痛苦的

一直追随Angular社区的人, 绝对知道我在说什么.我们从Angular 1升级到angular 2时, 绝对是一个彻底的改变, 包含新的API和新的模式. 显而易见的是:最终Angular 2是一个完全的重写, 即使有可用的升级选项.

而从版本2更改为版本4或5的改变将不会像从Angular 1那样. 它不会是一个完全的重写, 它将只是一些核心库的更改, 需要一个主要的SEMVER版本更改. 此外, 将有适当的调整阶段, 以允许开发人员调整其代码.

现在GOOGLE内部, Angular团队使用一个工具来处理自动升级, 甚至包括破坏性变更. 不过这仍然需要更详细的计划和调整, 但团队正在努力使这个工具具有更好的可用性, 目前看最有可能的情况是在2017年为angular 5释放出来.

Angular 就是 Angular

有人可能已经猜到了, "Angular 2" 也是一种阶段性称谓.总有一天,比如到了版本 4 或者 _5_, 这种称谓将被废弃, 我们将会开始只称呼它为 "Angular" 不带版本后缀.

同时, 我们现在应该开始尽量避免使用 ng2-angular2- 作为前缀的 GITHub/NPM库.

称谓说明

基本上从现在开始, 命名所有版本的Angular简单地叫做“Angular”. 尽量避免使用版本号, 除非真的有必要消除歧义.

比如:

  • 默认使用“Angular”(“我是一个Angular开发者”, “这是一个Angular的聚会”, “Angular生态系统正在快速增长”)

  • “Angular 1”, “Angular 2”, “Angular 4”当谈到一个特定的发布版本时(例如, 当谈到一个新引入的特性 - “这是一个介绍X特性X, 介绍在Angular 4”从Angular 1到Angular 2“, ”我为Angular 5提出这个更改“)

  • 在报告错误时使用完整的semver版本(“此问题自Angular 2.3.1开始存在”)

所有文档(甚至包括Angular 1),将在未来几周内从AngularJS中删除“JS”.

在博客文章, 课程, 书籍中, 或者当你定位一个非常特定的版本的Angular时, 考虑添加一个标题行:

"这篇文章使用Angular v2.3.1"

这有助于避免别人感到困惑, 特别是在撰写特定API时.

为什么没有 Angular 3 版本

核心Angular库存在于一个单一的GitHub存储库中, 位于github.COM/angular/angular. 所有这些都以相同的方式进行版本化, 但作为不同的NPM包分发:

包名 版本
@angular/core v2.3.0
@angular/compiler v2.3.0
@angular/compiler-cli v2.3.0
@angular/http v2.3.0
@angular/router v3.3.0

可以看到 @angular/router 的版本的当前未对齐. 由于router包版本的这种不对齐, 并且已经造成了一定的使用混乱. Angular 团队决定直接使用Angular v4. 采用这种方式, 将所有的核心包对齐, 这将更容易维护并且帮助避免将来的混乱.

为什么router 已经到了 v3.x.x?这是Angular团队发布 router v3 时的官方公告.

此外, 重要的是要了解Angular如何在Google中使用和集成(Igor在这里的主题演讲中谈到这一点). 所有Google应用程序使用Angular版本等于当前GitHub的Angular仓库的主分支. 每当一个新的提交到达master, 它将被整合到谷歌独立而庞大的mono-repo, 其中还有其他产品, 如地图, Adsense等. 因此, 在Google内部使用Angular的所有项目套件都将针对此新版本运行其广泛的测试. 这使得团队非常有信心去裁剪一个新版本, 因为它将包含已经在Google中进行过测试的Angular软件包的完全组合版本. 因此, 具有对齐的版本是完全有道理的, 并且随着时间的推移更容易维护它们, 这反过来有助于团队在发布新特征方面更有成效.

暂定释放时间表

Angular 团队基于时间周期的发布策略, 发生在三个周期:

  • 补丁每周发布.

  • 主要版本发布之后每月3次次要版本发布.

  • 主要版本, 每6个月更换一次, 易于迁移.

2017年开始之后接下来的3个月将专心完成 Angular 4.0.0.

总结

其实相关的也就那么几点:

  • 不管是 Angular 的版本或者其他框架或包的版本,我们都没有必要过度纠结. 了解版本发布规则和 CHANGELOG 即可.

  • 每次破坏性变更或者不兼容的升级,虽然会带来一时的痛苦,但是更多的是更强大的功能和性能,应该尽量向好的一面去看.

  • 敢于尝鲜是好事,但是某些尝鲜用在生产环境中,可能带来更多的是痛苦. 抖 M 属性的请无视此条d(・∀・*)♪゚

脚本宝典总结

以上是脚本宝典为你收集整理的为何 Angular 4 是 Angular 2 的下一个版本, 为什么没有 Angular 3.x全部内容,希望文章能够帮你解决为何 Angular 4 是 Angular 2 的下一个版本, 为什么没有 Angular 3.x所遇到的问题。

如果觉得脚本宝典网站内容还不错,欢迎将脚本宝典推荐好友。

本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ:384754419,请注明来意。