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

前端之家收集整理的这篇文章主要介绍了为何 Angular 4 是 Angular 2 的下一个版本, 为什么没有 Angular 3.x前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

很多人看到 Angular 从2.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(・∀・*)♪゚

猜你在找的Angularjs相关文章