目的

本文档记录了Apache Hadoop项目的兼容性目标。

列举了不同类型的Hadoop版本之间影响Hadoop开发人员、下游项目和最终用户的兼容性。对于每种类型的兼容性，本文档将：

  • 描述对下游项目或最终用户的影响
  • 在适用的情况下，指出Hadoop开发人员在允许不兼容更改时采用的策略。

所有Hadoop接口都根据预期受众和稳定性进行分类，以保持与之前版本的兼容性。有关分类的详细信息，请参阅Hadoop Interface Taxonomy。

目标受众

本文档面向Hadoop开发者社区。本文档描述了应该如何看待对Hadoop项目的更改。为了确保最终用户和第三方开发者对跨版本的兼容性有信心，开发人员社区必须确保开发工作符合这些政策。项目的提交者有责任验证所有更改，确保它们要么保持兼容性，要么明确标记为不兼容。

在组件内部，Hadoop开发人员可以自由使用私有和有限私有API，但在使用来自不同模块的组件时，Hadoop开发人员应遵循与第三方开发者相同的准则：除非明确允许，否则不要使用私有或有限私有接口，而是尽可能优先使用稳定接口，而不是进化或不稳定接口。在不可能的情况下，首选解决方案是扩展API的受众，而不是引入或延续与这些兼容性准则的异常。在使用Maven模块时，Hadoop开发人员应在尽可能的情况下对使用位于其他Maven模块中的组件保持相同的约束水平。

最重要的是，Hadoop开发人员必须注意其更改的影响。稳定的接口在主要版本之间不得更改。进化接口在次要版本之间不得更改。新类和组件必须根据受众和稳定性进行适当的标记。有关何时适用各种标签的详细信息，请参阅Hadoop Interface Taxonomy。作为一般规则，所有新接口和API应具有最受限制的标签（例如，Private Unstable），以不妨碍接口或API的意图。

结构

本文档按照各种兼容性关切划分为各个部分。在每个部分中，介绍性文本解释了在该部分中兼容性的含义，为什么兼容性很重要，以及支持兼容性的意图。随后的“政策”部分以具体术语阐明了治理政策是什么。

符号约定

关键词“MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“MAY”和“OPTIONAL”的解释应如RFC 2119所述。

弃用

Java API提供了@Deprecated注解，用于标记API元素以便将其标记为将要移除。该注解的标准含义是不应该使用API元素，并且可能会在以后的版本中删除。

在所有情况下，从API中删除元素都是一种不兼容的更改。该元素的稳定性应确定何时可以执行此更改。必须在删除稳定元素之前的完整主要版本中将其标记为已弃用，不得在次要或维护版本中删除。必须在删除进化元素之前的完整次要版本中将其标记为已弃用，不得在维护版本中删除。不稳定元素可以随时删除。在可能的情况下，不稳定元素在删除之前应至少在一个版本中标记为已弃用。例如，如果在Hadoop 2.8中标记了某个方法为已弃用，那么它在Hadoop 4.0之前不能被删除。

政策

稳定的API元素在被标记为已弃用（通过@Deprecated注解或其他适当的文档）的完整主要版本之前不得被删除。

在将API元素作为已弃用引入（表示它是一个预计会被移除的临时措施）的情况下，可以在随后的主要版本中删除该API元素。

在修改稳定API时，开发人员应优先引入新的方法或端点并弃用现有方法，而不是对方法或端点进行不兼容的更改。

兼容性类型

Java API

开发人员应该使用@InterfaceAudience和@InterfaceStability注解来描述Hadoop接口和类的预期受众和稳定性。

  • @InterfaceAudience捕获预期受众。可能的值有Public（用于最终用户和外部项目）、LimitedPrivate（用于其他Hadoop组件以及与之密切相关的项目，如YARN、MapReduce、HBase等）和Private（用于组件内部使用）。
  • @InterfaceStability描述了允许的接口更改类型。可能的值有Stable（稳定）、Evolving（进化）和Unstable（不稳定）。
  • @Deprecated表示包、类、成员变量或方法可能会在将来被移除，不应该使用。

注解可以应用于包、类或方法级别。如果方法没有隐私或稳定性注解，则应从它所属的类继承其预期受众或稳定性级别。如果类没有隐私或稳定性注解，则应从它所属的包继承其预期受众或稳定性级别。如果包没有隐私或稳定性注解，则应分别假定为Private和Unstable。

在元素的受众或稳定性注解与其父元素（明确或继承的）的相应注解存在冲突的情况下，元素的受众或稳定性（分别）应由更严格的注解确定。例如，如果一个Private方法包含在Public类中，则该方法应被视为Private。如果一个Public方法包含在Private类中，则该方法应被视为Private。

用例

  • Public-Stable API兼容性是为了确保最终用户程序和下游项目继续正常工作而需要的。
  • Public-Evolving API兼容性有助于在功能完全成熟之前使功能可供使用。
  • Limited Private-Stable API兼容性是为了允许跨次要版本升级各个组件。
  • Private-Stable API兼容性是为了支持滚动升级。
  • Private-Unstable API兼容性允许内部组件快速发展，而不必考虑下游消费者，这是大多数接口应该标记的方式。

政策 兼容性政策应由相关的包、类、成员变量或方法注解确定。

注意：从proto文件生成的API必须在滚动升级时保持兼容。有关更多详细信息，请参阅关于wire protocol兼容性的部分。因此，API和wire协议的兼容性政策必须手牵手进行。

语义兼容性 Apache Hadoop致力于确保API的行为在发布之间保持一致，尽管为了纠正错误而进行的更改可能导致行为更改。API的行为应由JavaDoc API文档规范，如果文档完整。当JavaDoc API文档不可用时，行为应由相关单元测试期望的行为规定。在没有JavaDoc API文档或单元测试覆盖的情况下，预期的行为被假定为明显的，并且应假定为接口命名所隐含的最低功能。

任何API的行为都可以更改以纠正不正确的行为，根据API的稳定性，此类更改应伴随着更新现有文档和测试和/或添加新文档或测试。

Java二进制兼容性（终端用户应用程序，即Apache Hadoop ABI） Apache Hadoop的修订版本应该保持二进制兼容性，以便终端用户应用程序继续正常工作，无需进行任何修改。同一主版本内的次要Apache Hadoop修订版本必须保持兼容性，以便在与原始构建目标相同的Apache Hadoop集群中使用时，现有的MapReduce应用程序（例如，最终用户应用程序和项目，如Apache Pig、Apache Hive等）、现有的YARN应用程序（例如，最终用户应用程序和项目，如Apache Spark、Apache Tez等）和直接访问HDFS的应用程序（例如，最终用户应用程序和项目，如Apache HBase、Apache Flume等）能够无修改且无需重新编译地正常工作。

对于特定的MapReduce应用程序，即使用org.apache.hadoop.mapred和/或org.apache.hadoop.mapreduceAPI的应用程序，开发人员社区应支持跨主要版本的二进制兼容性。MapReduce API应该在主要版本之间得到兼容支持。有关更多详细信息，请参阅hadoop-1.x和hadoop-2.x之间MapReduce应用程序的兼容性。

一些应用程序可能会受到对磁盘布局或其他内部更改的影响。有关不兼容更改处理方式的政策，请参阅后续部分。

本地依赖项

Hadoop包含几个本地组件，包括压缩、容器执行器二进制文件和各种本地集成。这些本地组件为Hadoop引入了一组本地依赖项，包括在编译时和运行时需要的依赖项，如cmake、gcc、zlib等。这组本地依赖项是Hadoop ABI的一部分。

政策 Hadoop在编译时和/或运行时所依赖的本地组件的最低要求版本应被视为Evolution（进化）。

这些最低要求版本在主要版本内的次要版本之间不应增加，尽管可能会因为安全问题、许可问题或其他原因而进行更新。

在主要版本内的次要版本之间必须更新Hadoop所依赖的本地组件时，尽可能地，更改应仅更改组件的次要版本而不更改主要版本。

Wire协议

Wire兼容性涉及在Hadoop进程之间传输的数据，即“通过网络传输”。Hadoop主要使用Protocol Buffers进行大多数RPC通信。为了保持兼容性，需要按照以下规定禁止修改。还应考虑非RPC通信，例如使用HTTP在快照的一部分或传输MapReduce map任务输出时传输HDFS镜像。通信可以分类如下：

  • 客户端-服务器：Hadoop客户端和服务器之间的通信（例如，HDFS客户端到NameNode协议，或YARN客户端到ResourceManager协议）。
  • 客户端-服务器（Admin）：值得注意的是，有一个由仅由管理命令使用的一部分客户端-服务器协议（例如，HAAdmin协议），因为这些协议只影响那些可以容忍终端用户（使用通用客户端-服务器协议）无法容忍的管理员。
  • 服务器-服务器：服务器之间的通信（例如，DataNode和NameNode之间的协议，或NodeManager和ResourceManager之间的协议）。

协议依赖 Apache Hadoop的组件可能具有包括它们自己的协议在内的依赖关系，例如Zookeeper、S3、Kerberos等。这些协议依赖应被视为内部协议，并受相同政策的管理。

传输 除了协议本身的兼容性外，保持跨版本通信还要求支持的传输也是稳定的。传输更改的最可能来源是来自安全传输（例如SSL）的更改。将服务从SSLv2升级到SSLv3可能会破坏现有的SSLv2客户端。任何传输的最低支持主要版本在主要版本内的次要版本之间不应增加，尽管因安全问题、许可问题或其他原因可能会进行更新。在主要版本内的次要版本之间必须更新传输时，尽可能地，更改应仅更改组件的次要版本而不更改主要版本。

服务端口被视为传输机制的一部分。为了防止破坏客户端，必须保持默认服务端口号的一致性。

政策 Hadoop wire协议是在.proto（Protocol Buffers）文件中定义的。客户端-服务器和服务器-服务器协议应根据其.proto文件中的受众和稳定性分类进行分类。在没有分类的情况下，协议应被假定为Private and Stable。

以下对.proto文件的更改应被视为兼容：

  • 添加一个可选字段，预期代码会处理由于与代码的旧版本通信而导致的字段丢失
  • 向服务添加新的rpc/method
  • 向消息添加新的可选请求
  • 重命名字段
  • 重命名.proto文件

  • 更改影响代码生成的.proto注释（例如，Java包的名称） 以下对.proto文件的更改应被视为不兼容：

  • 更改rpc/method名称
  • 更改rpc/method参数类型或返回类型
  • 删除rpc/method
  • 更改服务名称
  • 更改消息的名称
  • 以不兼容的方式修改字段类型（递归定义）
  • 将可选字段更改为必需字段
  • 添加或删除必需字段

  • 删除可选字段，只要可选字段具有合理的默认值以允许删除 以下对.proto文件的更改应被视为不兼容：

  • 更改字段ID
  • 重新使用以前已删除的旧字段。 未通过.proto文件定义的Hadoop wire协议应被视为Private and Stable。

除了被视为Stable的限制外，Hadoop的wire协议还必须根据以下要求在主要版本内的次要版本之间保持向前兼容：

  • 必须保持客户端-服务器兼容性，以允许用户在将服务器（集群）升级到较新版本之后继续使用较旧的客户端（反之亦然）。例如，Hadoop 2.1.0客户端与Hadoop 2.3.0集群的通信。
  • 必须保持客户端-服务器兼容性，以允许用户在升级服务器（集群）之前升级客户端。例如，Hadoop 2.4.0客户端与Hadoop 2.3.0集群的通信。这允许在完全升级集群之前部署客户端端的错误修复。请注意，由新客户端API或shell命令调用的新集群功能将无法使用。尝试使用尚未部署到集群的新API（包括数据结构中的新字段）的YARN应用程序可能会遇到链接异常。
  • 必须保持客户端-服务器兼容性，以允许升级单个组件而不升级其他组件。例如，将HDFS从版本2.1.0升级到2.2.0而不升级MapReduce。
  • 必须保持服务器-服务器兼容性，以允许在活动集群中存在混合版本，以便可以通过滚动方式无中断地升级集群。
  • 新的传输机制只能在次要或主要版本更改时引入。在主要版本内的次要版本之间必须继续支持现有传输机制。默认服务端口号应被视为Stable。

REST API

REST API的兼容性适用于公开的REST端点（URL）和响应数据格式。Hadoop REST API专门用于跨版本的客户端稳定使用，即使是主要版本也是如此。对于本文档而言，公开的REST API是指在公共文档中记录的API。以下是公开的REST API的非详尽列表：

  • WebHDFS
  • ResourceManager
  • NodeManager
  • MR Application Master
  • History Server
  • Timeline Server v1 REST API
  • Timeline Service v2 REST API

每个API都有一个特定的版本号。任何不兼容的更改都必须增加API版本号。

政策 公开的Hadoop REST API应被视为Public and Evolving。关于API版本号，公开的Hadoop REST API应被视为Public and Stable，即在API版本号内不允许进行不兼容的更改。REST API版本必须在完整的主要版本中标记为已弃用，然后才能删除。

日志输出

Hadoop的守护进程和命令行界面通过Log4j产生日志输出，旨在帮助管理员和开发人员理解和排查集群行为。日志消息旨在供人类阅读，但也支持自动化用例。

政策 所有日志输出应被视为Public and Unstable。对于日志输出，不兼容的更改是指使解析器无法找到或识别日志输出行的更改。

审计日志输出

多个组件具有审计日志系统，以机器可读的格式记录系统信息。对该数据格式的不兼容更改可能会破坏现有的自动化实用工具。对于审计日志，任何更改使得现有解析器无法解析日志的更改都被视为不兼容的更改。

政策 所有审计日志输出应被视为Public and Stable。对数据格式的任何更改都应被视为不兼容的更改。

指标/JMX

虽然Metrics API的兼容性受到Java API兼容性的限制，但Hadoop暴露的Metrics数据格式必须保持对数据消费者的兼容性，例如用于自动化任务。

政策 通过Metrics暴露的数据格式应被视为Public and Stable。

文件格式与元数据

用户和系统级别的数据（包括元数据）存储在各种格式的文件中。对存储数据/元数据的元数据或文件格式的更改可能导致版本之间的不兼容性。下面分别处理了每个文件格式类别。

用户级别的文件格式 对于终端用户用于存储其数据的格式的更改可能会阻止他们在后续版本中访问数据，因此非常重要以确保兼容性。这些格式的示例包括har、war、SequenceFileFormat等。

政策 用户级别的文件格式应被视为Public and Stable。用户级别的文件格式更改应在主要版本之间实现前向兼容性，并且在主要版本内必须实现前向兼容性。开发人员社区应更倾向于创建新的派生文件格式，而不是对现有文件格式进行不兼容的更改。这样的新文件格式必须以选择方式创建，这意味着用户必须能够继续使用现有的兼容格式，直到他们明确选择使用新的文件格式。

系统内部数据模式 Hadoop内部数据也可以存储在文件或其他数据存储中。更改这些数据存储的模式可能导致不兼容性。

MapReduce MapReduce使用诸如I-File之类的格式来存储特定于MapReduce的数据。

政策 所有MapReduce内部文件格式，例如I-File格式或作业历史服务器的jhist文件格式，应被视为Private and Stable。

HDFS元数据 HDFS将元数据（镜像和编辑日志）持久化为私有文件格式。对格式或元数据的不兼容更改会阻止后续版本读取旧的元数据。不兼容的更改必须包括一个升级现有元数据的过程。

根据更改中不兼容性的程度，可能会出现以下潜在情景：

  • 自动：图像会自动升级，无需显式的“升级”。
  • 直接：图像是可升级的，但可能需要一个显式的“升级”。
  • 间接：图像是可升级的，但可能需要先升级到中间版本。
  • 不能升级：图像是不能升级的。

HDFS数据节点将数据存储在私有目录结构中。对目录结构的不兼容更改可能会阻止旧版本访问存储的数据。不兼容的更改必须包括一个升级现有数据目录的过程。

政策 HDFS元数据格式应被视为Private and Evolving。不兼容的更改必须包括一个升级现有元数据的过程。升级过程应被允许需要多次升级。升级过程必须允许将群集元数据回滚到旧版本和旧磁盘格式。回滚必须还原原始数据，但不要求还原更新的数据。对格式的任何不兼容的更改必须导致模式的主版本号递增。

数据节点目录格式应被视为Private and Evolving。不兼容的更改必须包括一个升级现有数据目录的过程。升级过程应被允许需要多次升级。升级过程必须允许将数据目录回滚到旧的布局。

AWS S3A Guard元数据 用于在DynamoDB表中存储元数据的S3A Guard元数据存储; 因此，它必须保持兼容性策略。现在S3A Guard已被移除，这些表不再需要。

配置为使用S3A元数据存储而不是“null”存储的应用程序将失败。

YARN资源管理器状态存储 YARN资源管理器将有关集群状态的信息存储在外部状态存储中，以用于故障转移和恢复。如果用于状态存储数据的模式不保持兼容，资源管理器将无法恢复其状态，并将无法启动。状态存储数据模式包括指示兼容性的版本号。

政策 YARN资源管理器状态存储数据模式应被视为Private and Evolving。对模式的任何不兼容的更改必须导致模式的主版本号递增。对模式的任何兼容更改必须导致次要版本号递增。

YARN节点管理器状态存储 YARN节点管理器将有关节点状态的信息存储在外部状态存储中，以用于恢复。如果用于状态存储数据的模式不保持兼容，节点管理器将无法恢复其状态，并将无法启动。状态存储数据模式包括指示兼容性的版本号。

政策 YARN节点管理器状态存储数据模式应被视为Private and Evolving。对模式的任何不兼容的更改必须导致模式的主版本号递增。对模式的任何兼容更改必须导致次要

版本号递增。

YARN联邦状态存储 YARN资源管理器联邦服务将有关联邦集群、运行中的应用程序和路由策略的信息存储在外部状态存储中，以用于复制和恢复。如果用于状态存储数据的模式不保持兼容，联邦服务将无法初始化。状态存储数据模式包括指示兼容性的版本号。

政策 YARN联邦服务状态存储数据模式应被视为Private and Evolving。对模式的任何不兼容的更改必须导致模式的主版本号递增。对模式的任何兼容更改必须导致次要版本号递增。

命令行界面 (CLI)

Hadoop命令行程序可以直接通过系统shell或通过shell脚本使用。CLI包括用户界面命令（例如hdfs命令或yarn命令）和管理员界面命令（例如用于启动和停止守护程序的脚本）。

更改命令的路径、删除或重命名命令行选项、参数的顺序，或者更改命令的返回代码和输出都会破坏兼容性并对用户产生不利影响。

政策 所有Hadoop CLI的路径、用法和输出应被视为Public and Stable，除非被记录为实验性的并且可能发生变化。

请注意，CLI输出应与Hadoop CLI生成的日志输出视为不同。后者应受日志输出政策的约束。还要注意，对于CLI输出，所有更改都应视为不兼容的更改。

Web界面

Web界面，特别是Web页面的内容和布局的更改，可能会干扰尝试对Web页面进行屏幕抓取以获取信息的尝试。然而，Hadoop Web UI页面并不是为了被抓取，例如用于自动化目的。用户预计将使用REST API以编程方式访问集群信息。

政策 Hadoop Web UI应被视为Public and Unstable。

功能兼容性

用户依赖于Hadoop集群的行为在不同版本之间保持一致。导致集群行为出现意外不同的更改可能导致用户感到沮丧，并导致长时间的采用周期。不应添加新的配置来更改现有集群的行为，假设集群的配置文件保持不变。对于定义的任何新设置，应当小心确保新设置不会更改现有集群的行为。

政策 在相同的次要版本中，维护版本之间，不管更改是由于对系统或逻辑的更改还是由于内部或外部默认配置值的更改，都不得更改现有功能的默认行为或配置设置的含义。

在相同的主要版本中，次要版本之间，不应更改现有功能的默认行为或配置设置的含义，尽管可能需要进行不兼容的行为更改，例如修复正确性或安全性问题。在可能的情况下，此类行为更改应默认关闭。

Hadoop配置文件

用户使用Hadoop定义的属性来配置和为Hadoop提供提示，并使用自定义属性传递信息给作业。鼓励用户避免使用与Hadoop定义的属性的命名空间冲突的自定义配置属性名称，并应避免使用Hadoop使用的任何前缀，例如hadoop、io、ipc、fs、net、file、ftp、kfs、ha、file、dfs、mapred、mapreduce和yarn。

除了属性文件之外，Hadoop还使用其他配置文件来设置系统行为，例如公平调度器配置文件或资源配置文件。

政策 Hadoop定义的属性（名称和含义）应被视为Public and Stable。由Hadoop定义的属性暗示的单位不得更改，即使在主要版本之间也是如此。 Hadoop定义的属性的默认值应被视为Public and Evolving。

不受上述关于Hadoop定义的属性的规则管辖的Hadoop配置文件应被视为Public and Stable。对于特定配置文件格式的不兼容更改的定义取决于特定配置文件格式，但一般规则是，兼容更改将允许在更改之前有效的配置文件在更改之后仍然有效。

Log4j配置文件

Hadoop守护程序和CLI生成的日志输出受一组配置文件的管控。这些文件控制Hadoop各个组件输出的日志消息的最低级别，以及这些消息在何处以及如何存储。

政策 所有Log4j配置应被视为Public and Evolving。

目录结构

源代码、构建工件（源代码和测试）、用户日志、配置文件、输出和作业历史都存储在本地文件系统或HDFS上。更改这些用户可访问的文件的目录结构可能会破坏兼容性，即使在保留原始路径的情况下通过符号链接（例如，当通过配置为不跟随符号链接的servlet访问路径时）。

政策 源代码和构建工件的布局应被视为Private and Unstable。在主要版本内，开发社区应保留总体目录结构，尽管可以在不提前通知的情况下添加、移动或删除单个文件。

配置文件、用户日志和作业历史的目录结构应被视为Public and Evolving。

Java类路径

Hadoop提供了几个客户端工件，应用程序使用这些工件与系统进行交互。这些工件通常对常见库有自己的依赖关系。在这些依赖关系暴露给最终用户应用程序或下游消费者（即未遮蔽的情况下）的情况下，对这些依赖关系的更改可能会导致破坏。强烈建议开发人员通过使用诸如shading等技术来避免向客户端暴露依赖关系。

在依赖关系方面，添加依赖关系是一种不兼容的更改，而删除依赖关系是一种兼容的更改。

一些构建在Hadoop上的用户应用程序可能将所有Hadoop JAR文件（包括Hadoop的库依赖项）添加到应用程序的类路径中。添加新的依赖项或更新现有依赖项的版本可能会干扰应用程序的类路径，因此可能影响其正确操作。因此，建议用户不要采用此做法。

政策 Hadoop客户端工件暴露的依赖关系应被视为Public and Stable。未向客户端暴露的任何依赖关系（因为它们被遮蔽或仅存在于非客户端工件中）应被视为Private and Unstable。

环境变量

用户和相关项目通常使用Hadoop导出的环境变量（例如HADOOP_CONF_DIR）。因此，删除或重命名环境变量可能会影响最终用户应用程序。

政策 Hadoop使用的环境变量以及通过YARN提供给应用程序的环境变量应被视为Public and Evolving。开发社区应限制在主要版本发布中对其进行更改的情况。

构建工件

Hadoop使用Maven进行项目管理。对生成工件内容的更改可能会影响现有的用户应用程序。

政策 Hadoop测试工件的内容应被视为Private and Unstable。测试工件包括从测试源代码生成的所有JAR文件以及文件名中包含“tests”的所有JAR文件。

Hadoop客户端工件应被视为Public and Stable。客户端工件包括以下内容：

  • hadoop-client
  • hadoop-client-api
  • hadoop-client-minicluster
  • hadoop-client-runtime
  • hadoop-hdfs-client
  • hadoop-hdfs-native-client
  • hadoop-mapreduce-client-app
  • hadoop-mapreduce-client-common
  • hadoop-mapreduce-client-core
  • hadoop-mapreduce-client-hs
  • hadoop-mapreduce-client-hs-plugins
  • hadoop-mapreduce-client-jobclient
  • hadoop-mapreduce-client-nativetask
  • hadoop-mapreduce-client-shuffle
  • hadoop-yarn-client

所有其他构建工件应被视为Private and Unstable。

硬件/软件要求

为了跟上硬件、操作系统、JVM等软件的最新进展，新的Hadoop版本可能包含需要比先前Hadoop版本更先进的硬件、操作系统版本或JVM版本的功能。

对于特定环境，升级Hadoop可能需要升级其他依赖软件组件。

政策 硬件

  • 架构：Intel和AMD是社区当前支持的处理器架构。社区没有将Hadoop限制在特定的架构上的计划，但可能会有特定处理器家族的优化。不应在首次被文档记录为完整的主要版本之前将对任何处理器架构的支持取消，并且不得在至少一个完整的次要版本之前将其废弃。
  • 最低资源：虽然Hadoop守护程序所需的最低资源不能保证，但是在一个次要版本中，开发社区应避免增加要求。

操作系统：

  • 社区应在一个次要版本中保持相同的最低操作系统要求（操作系统内核版本）。目前GNU/Linux和Microsoft Windows是社区官方支持的操作系统，而Apache Hadoop已知在其他操作系统上（如Apple MacOSX、Solaris等）也能够正常工作。不应在首次被文档记录为完整的主要版本之前将对任何操作系统的支持取消，并且不得在至少一个完整的次要版本之前将其废弃。

JVM要求：

  • 在同一主要版本的次要发布之间，JVM的要求不得更改，除非涉及的JVM版本不再受支持。JVM版本要求可能对不同的操作系统或甚至操作系统版本有所不同。

Hadoop支持的文件系统，例如通过FileSystem API支持的文件系统，在同一主要版本的次要发布之间不应不受支持，除非提供了迁移到替代客户端实现的路径。

参考

  • 以下是与该主题相关的一些相关JIRA和页面：
    • 该文档的演进 - HADOOP-9517
    • Hadoop-1.x和Hadoop-2.x之间MapReduce端用户应用程序的二进制兼容性 - MapReduce Compatibility between hadoop-1.x and hadoop-2.x
    • 根据接口分类计划的接口的注解 - HADOOP-7391 Hadoop Interface Classification
    • Hadoop 1.x版本的兼容性 - HADOOP-5071
    • Hadoop路线图页面，记录了其他发布政策

参考资料

https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/Compatibility.html