往年 8 月 Go 开发团队发布了 Go 2.0 的设计草案，包括错误处置和泛型这两大主题。如今备受注目的 Go 2.0 又有了新意向 —— Go 开发团队在其官方博客表示，Go 2 曾经被放置上了！目前 Go 2 已进入确定变更提案的阶段，并发布了提案评价流程。
废话不多说，先来看看 Go 2.0 有哪些值得关注的内容：
1.最大水平保持对 1.x 的兼容，以避免分裂 Go 言语生态系统
2.采用增量晋级的方式，而非独自发布严重更新版本
3.实施新的提案评价流程，以评价尚未处置且被标记为提案的 issue
4.将会在 Go 1.13 版本中选择 Go 2 部分的提案
早在2017年的 GopherCon 大会上，Russ Cox（Go 中心开发团队的技术 leader）就曾经正式末尾思索 Go 的下一个大版本。事先官方非正式地将它称为 Go 2，但我们知道，所谓的 Go 2.0 并非一个独自的严重更新版本，而是经过“增量更新(incremental)”的方式以逐渐抵达 "Go 2.0"。所以本文对这个未来版本的称号 —— 也暂且用 Go 2 来描画。
Go 1 和 Go 2 之间的主要区别在于主导权的不同。谁将影响设计，又该如何做出决策？我们都知道，Go 1 的降生是小团队努力的结果，受外部影响不大；而到了 Go 2，尤其是经过将近 10 年的开展后，Go 言语的生态曾经十分庞大，因此它也更多地遭到社区的驱动和影响。阅历了这些，Go 开发团队也了解到了更多一末尾不知道的与言语特性和库相关的知识 —— 这些都来自于 Go 社区的反应。
2015年，Go 开发团队引入了提案流程，以搜集特定类型的反应：针对言语和库变更方面的提案。由 Go 开发团队初级成员组成的委员会活期审查、分类和决议社区提交的提案。这个流程十分有效，但作为该进程的一部分，他们疏忽了一切不向后兼容的提案，只是将其标记至 Go 2。到了2017年，Go 开发团队也中止停止任何类型的向后兼容的“增量”言语特性变更，由于他们以为无论变更多么小，都要有更片面的支持方案，并将 Go 2 思索在内。
关于这些累积上去的提案，官方表示如今是时分采取举动了！
近况本文发布时，官方表示目前在 Go 2 的提案中，大约有 120 个尚未处置且被标记为提案的 issue。这些提案都触及到重要的库或言语特性变更，而它们通常不能与 Go 1 相互兼容。Ian Lance Taylor 和 Robert Griesemer 不断在研讨这些提案，并对它们停止了分类(Go2Cleanup, NeedsDecision 等)，以了解这些提案背后的含义并使它们后续更易停止。此外，他们还兼并了相似的提案，并封锁了那些看似清楚超出 Go 范围的提案，或许其他方面无法完成的提案。
早期出现的两个提案包括更好的错误处置和泛型，而它们的草案已在往年的 GopherCon 大会上发布，等候更多的探求开展。至于剩余的提案，官方提到，他们不希望过度影响数百万 Go 开发者以及如今的 Go 代码，更不想冒着分裂生态系统的风险去改版 Go 2，因此 Go 2 无法做出太多变更，每一个变更都需求细心选择。为此，这些提案都将运用新的提案评价流程来决议去留与开展。
提案评价流程提案评价流程旨在搜集对少数选定提案的反应意见，以作出最终决议。这个进程或多或少会与发布周期并行停止，包括以下步骤：
提案选择：Go 开发团队选择大批看起来值得思索接受的 Go 2 提案，但尚未做出最终决议。
提案反应：Go 开发团队将发布一份列出所选提案的公告，公告会向社区解释提案的初衷并搜集反应意见。在这个步骤中，社区可提出建议。
完成：依据来自社区的反应意见，提案末尾完成。
针对所完成的提案的反应：在开发周期中，Go 开发团队和社区试用新功用并且搜集进一步的反应意见。
启动决策：在三个月的开发周期完毕时，依据在发布周期中搜集的阅历和反应意见，Go 开发团队会思索变更的预期收益或产生的额外成本，从而最终决议能否发布每个变更。一旦发布，这些被发布的提案就成为言语和库的一部分。未被发布的提案能够会重新起草，但也有能够会被永世拒绝。
可以看到，经过两轮的反应进程，可对提案停止有效的挑选，从而避免“功用蔓延(feature creep)”，有助于保持 Go 言语的繁复。
提案选择标准一项提案至少要满足以下这些条件：
处置大部分运用者觉得重要的成绩
不会对其他运用者形成太大的影响
提供一个明晰且易于了解的处置方案
条件1确保提案所做的任何变更都可以协助到尽能够多的 Go 开发者（使他们编写的代码更强健、正确性更初等），条件2则保证了变更将给运用者带来的影响降到最低。
至于条件3，假设提案不能满足该条件，它将不会被完成。即使这项提案可以处置一个很重要的成绩，思绪也很好，但在没有完成方案的状况下，它将会被拒绝，并需求重新起草。
下一步在这篇文章发布时，Go 开发团队表示曾经执行提案评价流程的第一步，并末尾了流程的第二步，关于详细的提案可点此停止查看。
关于 Go 开发团队曾经明白并经过的提案，将会继续完成（即评价流程的第3步）。开发团队表示希望在下一个发布周期的第一天（暂定于2019年2月1日）完成这些提案变更的完成，所以这次能够会在较早的时间末尾停止，以留出两个月的反应时间（2018年12月至2019年1月）。
而在为期3个月的开发周期中（2019年2月至5月），被选择的提案将会被完成，每位运用者都可以体验新功用并停止反应（评价流程的第4步）。
最后，在长久的解冻期后（2019年5月1日），Go 开发团队会最终决议能否永世保留新功用（并保证这些功用与 Go 1 兼容），或是保持这些功用（评价流程的最后一步）。
Go 开发团队表示这是初次采用这一流程，因此在解冻阶段将会是反思这个流程，并在必要时停止调整的好时机。我们也不妨拭目以待吧！
【编辑引荐】
开发者搭建谷歌产品墓地，掩埋谷歌淘汰的产品
最好的编程言语？美国出数据了，Java吃香，PHP败了
“双面”少儿编程：一边疯狂挤入，一边狼狈参加
微软的TypeScript最受JavaScript开发者喜爱
Netflix 宣布中止开发 Hystrix
(责任编辑：admin)