项目RFC 3：依赖关系管理¶
- 作者
克里斯蒂安·埃弗斯
- 联系
- 状态
采用
- 最后更新
2019-01-16
总结¶
本文档为项目中的依赖关系管理定义了一套指导原则。PROJ是许多下游软件包中的核心组件，清楚地说明库的哪些依赖项是非常有价值的。本文档涉及编程语言标准以及库依赖项和构建工具的最低要求版本。
建议采用滚动更新方案，确保项目即使在较旧的系统上也能充分访问，并跟上技术的发展。该方案分为两部分，一部分涉及PROJ中所用编程语言的版本，另一部分涉及PROJ所依赖的软件包。
随着本RFC的采用，用于
编程语言总是比最新的标准至少落后两个版本
软件包将始终至少使用两年（补丁版本除外）
编程语言标准的改变只能在PROJ的新的主要版本中引入。软件包依赖项的更改可以通过PROJ的小版本发布引入。更改依赖项的版本要求需要得到PSC的批准。
遵循上述规则集将确保除最保守的PROJ用户外的所有用户都能够构建和使用库的最新版本。
在下面的部分中，我们将概述有关编程语言和软件依赖性的详细信息。RFC以一个bootstrapping部分结束，该部分详细说明接受RFC后依赖项的状态。
背景¶
Proj传统上是用C89编写的。直到最近，项目还没有定义和正式接受构建系统等的正式要求。 RFC2 正式引入了对C++11和SQLite 3.7的依赖关系。
本RFC描述了版本或标准要求的滚动更新。滚动更新方案背后的原因是，越来越明显的是，C89已经过时，并为贡献者创建了一个不太理想的开发环境。已经注意到，最常用的编译器现在都支持C的最新版本，因此C89的严格使用不再像以前那样重要。
类似地，对PROJ所依赖的其他工具和库的滚动更新将确保代码库能够保持现代化，并与开放源码软件生态圈的其他部分保持一致。
C与C++¶
跟随 RFC2 PROJ是用C和C++编写的。在编写时，核心库是基于C的，而在RCF2中描述的代码是用C++编写的。核心库主要用C编写，编译为C++。PROJ的小部分，如测地线算法，仍然被编译为C，因为没有明显的好处与C++编译器编译。这在将来可能会改变。
C和C++标准都是按规则间隔更新的。在标准更新之后，编译器制造商需要时间来完全实现这些标准，这使得适应新标准可能很麻烦，如果做得太快的话。另一方面，等待太长时间来采用新的标准最终会让代码库感觉陈旧，而新的贡献者更可能离开，因为他们不想使用过去的工具。使用滚动更新方案，这两个问题都可以通过始终保持在最新标准的后面来管理，但距离不会太远，以至于潜在的贡献者会被吓跑。保持一个总是落后于标准两次迭代的策略被认为是这两个关注点之间的最佳组合。
C有四个ISO标准化品种：C89、C99、C11、C18。在本文件中，为了便于阅读，我们提到了它们的非正式名称。C++有五种：C++98、C++03、C++11、C++14、C++17。在采用此RFC项目之前，使用的是C89和C++11。对于C，这意味着所使用的标准比最新标准落后三次。C++落后了两次迭代。遵循此RFC中的规则，Proj中使用的所需C标准被允许比最新标准落后两次迭代。这意味着，只要项目PSC承认这种变化，就有可能改变到C99。
当一个新的C或C++标准发布时，PRJ应该考虑将其要求更改为行中的下一个标准。对于C++来说，这意味着每三年大约有一次标准的变更，对于C来说，标准更新之间的周期预计会更长。新的编程语言标准的改编应该与PROJ的主要版本发布相协调。
软件依赖性¶
在编写PROJ时，它依赖于很少的外部包。事实上，只有一个运行时依赖关系存在：SQLite。构建项目还需要两个外部依赖项中的一个进行配置：Autotools或CMake。
与编程语言标准一样，最好是软件依赖性稍微落后于最新的开发。因此，要求项目依赖项中支持的最低版本至少为两年，最好是更久。这不是一个要求，最低版本的依赖总是严格保持两年后，目前的发展，但它是允许的情况下，未来发展的项目保证更新。最低版本要求的变更允许在项目的次要版本发布时发生。
在编写2010年发布的SQLite it 3.7所需的最低版本时。CMake目前至少需要2.8.3版本，该版本也是在2010年发布的。
自举¶
这个RFC附带了一套指导方针，用于将来处理PROJ的依赖关系。到目前为止，依赖关系还没有得到一致的处理，有些依赖关系没有得到项目管理机构的正式批准。因此，建议项目依赖性的最低版本，以便在接受本RFC时，项目将具有以下外部要求：
收养状况¶
RFC于2018年1月19日通过，由以下PSC成员提供+1
克里斯蒂安·埃弗斯
甚至鲁奥
托马斯·克努森
霍华德巴特勒