WG21对于每三年的标准发布制定了严格的时间表（请参阅
P1000 ）。 而且没有延迟。
在每个周期中，我们都会定期收到“为什么如此严格？”的问题，特别是来自不熟悉委员会历史和当前状况的新成员。 在与科隆政府进行的初步电话会议中，一些人建议描述我们为什么这样做以及如何决定采用此时间表。
我以问题和答案的形式将所有这些内容画在下一个P1000草案中，并在前往科隆的路上将副本发送给委员会成员。 该材料将在P1000的下一个公开版本中发布，我们将在目前的几周内将其发送。
但是，FAQ草案可能会引起公众的兴趣，因此，我向您提供了它的副本。 我希望在大多数情况下它将对您有用，以某些方式启发您，甚至可能使您有所收获。
标准中有错误，您应该推迟C ++ 20吗？
当然可以。
我们正以选定的速度朝着给定的方向发展：计划于去年进行错误修复，因此早期C ++“ 19”（科纳）的时间表为停止在C ++“ 20”中添加功能设置了最后期限。我们有一年的时间来修复错误，包括今年夏天处理来自不同国家的评论。 在2020年初之前（在科隆，贝尔法斯特和布拉格举行的会议），我们必须提供反馈并应用其他解决方案来解决问题以及错误修复。
如果我们再召开一两次会议，则可以添加一个<feature name>，它已经准备好了，所以您应该推迟C ++ 20吗？
当然可以。
等待更多的会议（在布拉格之后）举行，C ++ 23将开始营业，首先我们将投票赞成在C ++ 23的工作草案中添加<功能名称>。 因此我们采用了这些概念：它们还没有为直接从TS过渡到C ++ 17做好准备。 因此，在有关C ++ 20的第一次会议（在多伦多）上，他们投票决定将概念的基本功能转移到C ++ 20草案中，这给了很多时间来改进和完善TS（非“模板”语法）的其余矛盾部分。明年（圣地亚哥）。 现在所有功能都准备就绪。
这似乎太严格了。 为什么以固定间隔（三年）发布IS版本？
因为在C ++ IS发行版中，这是项目管理的两个主要选项之一，并且经验表明，此选项比第二个更好。
C ++ IS发行版的项目管理有两个选择？
很高兴你问。
对于发行版，有两个主要选项：选择功能或发行日期，并且选择一个时，您将失去对另一个定义的控制。 您不能同时控制两者。 简而言之：
我解释：
（1）“什么”：我们选择功能并准备就绪，无需选择发布时间 。 如果事实证明您需要更多时间来确定标准草案中的功能，那么整个世界都将等待您。 您需要开发需要几年时间才能开发的大型功能，然后尝试在稳定版本的同时完全停止使用新功能。
C ++ 98（预期在1994年左右发布，Björn说，如果发行不成功，那将是一个失败），C ++ 11（称为0x，因为x预计在2007年出现） ） 这是无限期的“让患者不受遮挡”的方法，从而导致集成测试和发布的延迟。 反过来，这又导致市场对下一个标准的发布时间以及是否将其全部发布存在很大的不确定性（是的，不仅是开发参与者，而且甚至在1996年和2009年，委员会的一些成员都曾对此表示怀疑。有任何相关版本）。 几年来，大多数编译器都不符合该标准，因为没有人知道该委员会将在新版本中推出多少不兼容的更改，或者什么时候可以期待？ 这导致社区可以使用的编译器中的C ++支持多种多样且分散化。
我们为什么要这样做，我们是白痴吗？ 并非如此，他们只是没有经验，而...说“乐观”。 这是一条充满良好意图的道路。 在1994-1996年和2007-2009年，我们真的相信我们现在将再次召开一，两次或三次会议，我们将竭尽所能，每一次会议最多可推迟四年。 现在，他们从自己的经验中看到，一两年之内无法转让。
幸运的是，由于选项（2），一切都发生了变化。
（2）“何时”：我们选择发布日期并交付已准备就绪的功能，您无需选择一组功能 。 如果事实证明需要更多时间来完善标准草案中的功能，则我们将其丢弃并交付准备就绪的功能。 您可以继续处理大型功能，创建多个版本需要花费时间，但是要在第三方“分支”中进行，尽快将其添加到IS master分支中。 而且，您不断地开发功能，因为它们的开发与当前版本完全分开（没有很大的连接点）。
自2012年以来，我们一直坚持这种方法，并且不想放弃它。 这是“定期修补患者”的方法，由于强制进行规则的集成以及拒绝在IS草图中添加工作直到达到一定的稳定性水平（通常在要素分支中），导致对更高质量的期望。 它还创建了市场可以依赖的可预测的发布周期。 多年以来，编译器的作者越来越早地开始发行下一个版本，以发行符合该标准的产品版本，这是前所未有的。 到2020年，我们预计随着标准的发布，将在一年内发布完全兼容的实现，这也是前所未有的。 这仅是为了整个市场（开发人员，用户，教师）的利益。
还要注意，自从我们开始坚持这种方法以来，我们已经开始做更多的事情（如果通过大型，中型和小型功能来衡量）并且质量更高（如果通过严格减少错误报告和对代码的评论来衡量）每个标准的草案）。 尽管我们提供了我们准备的东西（如果我们没有处理任何东西，我们也不会提供）。
您对方法（2）有多认真？ 如果根据该委员会的一位权威成员说，某个重大功能“几乎已准备就绪”，那么您将很想稍等一下，对吗？
非常认真，没有。
我们有统计数据：2016年，在杰克逊维尔，当我们最终决定C ++ 17的功能时，BjörnStraustrup在全体会议上发表了讲话，提出了将C ++ 17中的概念包括在内的建议。 当没有达成共识时，直接问Straustrup他是否想将C ++ 17的发布推迟一年，以便在其中包含一些概念。 比约恩毫不犹豫地回答“不”，并补充说，没有概念的C ++ 17比具有概念的C ++ 18或C ++ 19更重要，尽管Straustrup从事这些工作已有15年左右。 选择是这样的：（2）我们发布没有概念的C ++ 17，然后发布包含概念的C ++ 20（我们做到了），或者（1）将C ++ 17重命名为C ++ 20，这是同构的（2）除了跳过C ++ 17并拒绝发布已经为C ++ 17准备的内容外，其他情况除外。
（1）和（2）之间的权衡如何？ 说，我们通常会坚持（2），但是如果您需要完善功能，就具有“一点点”的灵活性来获得“一点点”的额外时间？
否，因为事实证明（1）。
弗雷德·布鲁克斯（Fred Brooks）在
《神话人月》中通俗地解释了“神话中的小转移”，并得出结论：“
不允许进行任何小转移 。”
假设我们移植了C ++ 20。 无论我们多么努力避免它，我们都必须从（2）回到（1），同时也不会获得任何好处。 如果我们决定推迟对C ++ 20的完善，那么我们将标准推迟至少两年。 没有转移一个或三个会议这样的概念，因为在此期间其他人将继续（很公平）说：“好吧，我的功能只需要再召开一次会议，我们仍重新安排了会议，让我们转移另一个会议。” 而且，如果我们至少转移两年，则意味着C ++ 20变为C ++ 22，最有可能成为C ++ 23 ...，但是我们已经准备交付C ++ 23！ -无论如何，我们将交付C ++ 23，唯一的区别是，我们
不会在完成大量工作，准备发布的情况下
不转移C ++ 20，也不会让整个世界再等三年。 延迟不会使这些功能，大多数功能或全部功能受益。
因此，该句子等效于“让C ++ 20转换为C ++ 22或C ++ 23”，并获得一个简单的答案：“是的，我们将拥有C ++ 23，但除了C ++ 20之外，还有不能代替他。” C ++ 20延迟意味着跳过C ++ 20而不是发布好的，稳定的，最终的产品，这样做将没有任何好处。
但是功能X损坏了/比我们需要花费更多的时间来解决C ++ 20中的错误！
没问题！ 我们可以削减它。
在这种情况下，需要有人用EWG或LEWG（视情况而定）写一封信，并附上情况说明，并提出从IS草案中删除该功能。 这些小组将考虑上诉，如果他们确定该功能已损坏（并且通风道同意），则该功能将被推迟到下一个C ++版本。 我们已经使用C ++ 0x概念做到了这一点。
但是在（1）的情况下，我们不仅将转移此功能，还将
整个功能集从C ++ 20转移到C ++ 23！ 那将是...破产。
方法（2）是否意味着“主要/次要”发布？
不行 首先，我们一直这样说，直到我们意识到（2）仅意味着即使从“主要/次要”版本的角度来看，也不需要选择一组功能。
方法（2）仅表示“我们运送已准备好的东西”。 获得版本：
- 相同的功能尺寸（通常是平均尺寸）“较小”，因为花在功能开发上的时间更少（例如，每个功能的使用时间少于三年），并且通常在发行版中获得相同数量的完整功能；
- 并且“较大”功能具有可变的大小（不必一次或两次），这需要花费更多的时间（例如，每个超过三年），并且每个IS版本都包含了为完成发布而要包含的所有这些功能。 因此，在某些发行版中，更多的发行版中有更少的发行版。
C ++ 14和C ++ 17相对较小，因为在标准化实施提案（例如合同）和TS中的“功能分支”（例如概念）中描述的长期使用的功能上花费了大量标准化工作。
C ++ 20是一个很棒的发行版...
是的 C ++ 20具有许多主要功能。 最大的三个以“ ko”（概念，合同，协程）开头，因此我们可以将其称为co_cpp20。 或co_dependent。
...并且在C ++ 20的三年周期中做得还不够吗？
不，请参见上面的“每次一次没有必要”。
C ++ 20之所以大，不是因为我们三年来做了更多的事情，而是因为有很多长期的发展（包括至少两个，我们自2012年以来一直以P句和TS分支的形式进行当前开发） ）已准备就绪，因此决定将它们包含在同一版本的IS草案中。
几乎总是，主要功能已经开发了很多年。 C ++ 98和C ++ 11的方法（1）与方法（2）之间的主要区别在于，在C ++ 98和C ++ 11中，发布推迟到所有这些功能都准备好为止，现在我们发布了一旦准备就绪，我们将与他们一道释放更多。
C ++ 20与C ++ 14和C ++ 17经历了相同的三年周期。 在过去三年中，我们没有比前两个周期做得更多，只是在主要功能上增加了更多。 如果它们中的任何一个还没有准备好，那么我们将它扔掉，并已经针对C ++ 23完成了。 如果发生这种情况，我们将在实施提案中进行报告并说明原因。
C ++ 14 + 17 + 20构成了继C ++ 98（1989-1998）和C ++ 11（2002-2011）之后的第三个九年周期（2011-2020）。 但是，由于我们坚持方法（2），所以我们
还发布了准备在三年和六年周期结束时进行的开发。
在产品开发过程中而不是产品发布后发现错误不是更好吗？
当然更好。
但是，如果我们谈论的是C ++标准发布延迟的原因，那么这个问题意味着两个错误的假设：
- 在发布该标准之前，功能没有出现并且没有被使用（对于许多人来说，已经有生产经验）；
- 并且所有功能可以一起使用，直到发布标准为止（不允许）。
我解释：
- C ++ 20的大多数主要功能都以至少在一个编译器中反映在标准的当前草案中的形式实现，并且在大多数情况下已在生产代码中使用（即，对于非常满意的用户已经可用） 。 例如，协程（在本文开始前仅五个月推出）在MSVC的生产中使用了两年，在Clang的生产中使用了一年，这让大型客户（例如Azure和Facebook）感到非常满意。
- 在用户开始在生产中使用这些功能（即在发布标准之前）之前，我们不会遇到很多功能交互的问题，因为许多开发人员将等待其发布以实施不同的项目。 而且，如果我们对发布时间不确定，则这些实现也将被延迟。 好了，他们仍然实现了某些东西，但是在开发人员确定我们准备发布之前，很多东西都会暂停。 询问<最喜欢的编译器名称>的创建者，在实现<大功能名称>时，在发布的标准中出现之前发生了什么。 在许多情况下，有必要反复实施，并反复打断消费者。 因此，开发人员宁愿等待委员会批准某些功能。
最后，不要忘记交互功能的问题。 我们不仅准备就绪后就释放它们，在那之后我们仍然需要时间来搜索功能之间的交互问题并增加对这种交互的支持，而在广泛使用新功能之前，我们根本无法找到这些支持。 不管我们延迟多长时间发布该标准，都将始终存在一些交互作用，我们只能在很长时间以后进行探索。 您需要借助灵活的设计来管理这种风险，确保功能的兼容性，而不是迫不及待地摆脱所有风险。
标准永远不会是完美的……您不发布错误吗？
是的
如果发现该功能尚未就绪，则必须将其从发行版中删除。
如果我们发现某个功能可以做得更好，并且知道该更改可能是向后兼容的，那么这并不是现在拒绝其发布的理由。 可以在以下C ++中作为扩展发布。
我们有意发布我们计划在将来进行改进的功能，同时我们有信心可以保持向后兼容。
但是，您是否不应该尝试最小化发布错误？
是的 我们正在努力。
但是，我们不会尽一切风险。 拒绝发布似乎已经准备就绪的东西还有风险和（可能）的代价。 通常，我们是对的。
您确定现在的质量比使用方法（1）更好吗？
是的
根据客观指标，来自不同国家/地区的评论和错误报告，C ++ 14和C ++ 17是我们最稳定的版本，根据这些指标，它们比C ++ 98和C ++ 11高3-4倍。 原因恰恰在于发行的规律性，首先在TS分支中放置大型功能部件（包括对其与主要标准集成的完整描述）以及随后的注入（当我们确信已准备就绪时）。
自2012年以来，主要标准
始终保持在几乎准备就绪的状态（因此，即使是与C ++ 98和C ++ 11标准发行版一样高质量的工作草案）。 以前从未发生过这种情况，当时我们使患者长期处于不安全状态，周围散布着许多问题和器官，我们将很快予以解决。 现在我们知道我们可以维持高质量的工作进度，因为我们始终处于准备发布的状态。 如果愿意，您甚至可以立即发行CD，而无需在科隆开会，而且CD C ++ 98或C ++ 11的质量仍然比以前高得多（实际上是CD及其发行的标准） 。 考虑到C ++ 98和C ++ 11都取得了成功，现在的质量更高的理解意味着我们走在了正确的道路上。
C ++ 98和C ++ 11大约开发了9年，是非常好的产品...
是：1989-1998年和2002-2011年。
...和C ++ 14和C ++ 17是次要版本。 C ++ 20是主要版本吗？
我再说一遍，我认为将C ++ 14 + 17 + 20作为一个整体进行比较是正确的：这是我们的九年周期，但是由于我们坚持采用方法（2），所以我们也发布了那些准备完成三年和六年周期的开发工作。
方法（2）允许您实现基于功能的目标，例如下一个C ++的P0592 ？
当然可以！ 虽然其中没有像“应该包括这些功能”这样的字眼，但是那样的话，这就是方法（1）。
争取某些功能并给其中一个优先级是正常的，但这是优先级的问题。 到目前为止，我们只会采取已准备好的工作，但是我们可以首先选择要进行的工作，以便尽快进行准备。