为什么会有这样的需求呢？举个例子，比如 Hadoop 3.0 有些比较 fancy 的功能，但是用户正在用着 2.8.5，但是用户也想用到 3.0 那个 fancy 的功能，那么这里就需要评估一下，把这个 3.0 的 Feature 合进来 2.8.5 了。
但是要注意，这种向后兼容，并不总是可以的，尤其是垮了大版本的软件，特别是那些大的特性，需要仔细评估才能告诉用户是否可以这么做，所以这种需求，不要一下子就答应了，要给自己留点 buffer。
一般这种向后兼容的代码合并，要比较小心，当然最好就是可以本地 debug，一边修代码，一边去做 debug，否则只是机械地合并了些代码，但是如果 Feature 里一个 if-else 的反向，就能把你给整懵逼了。
这里举个例子，针对 Yarn 的这个问题 YARN-7699，可以看到，用户是 2.8.4 的版本有问题，但是 patch 只合进去了其他版本。
那用户实在不想升级 Hadoop 版本呢，那就得仔细查看 patch 的内容，需要认真评估一下。当然了，例子里这个 patch 非常简单，只要合并进去代码就可以了。
代码语言：javascript复制//org/apache/hadoop/yarn/server/resourcemanager/scheduler/common/fica/FiCaSchedulerApp.java
/**
* Recalculates the per-app, percent of queue metric, specific to the
* Capacity Scheduler.
*/
@Override
public synchronized ApplicationResourceUsageReport getResourceUsageReport() {
ApplicationResourceUsageReport report = super.getResourceUsageReport();
Resource cluster = rmContext.getScheduler().getClusterResource();
Resource totalPartitionRes =
rmContext.getNodeLabelManager()
.getResourceByLabel(getAppAMNodePartitionName(), cluster);
ResourceCalculator calc = rmContext.getScheduler().getResourceCalculator();
float queueUsagePerc = 0.0f;
if (!calc.isInvalidDivisor(totalPartitionRes)) {
float queueAbsMaxCapPerPartition =
((AbstractCSQueue)getQueue()).getQueueCapacities()
.getAbsoluteCapacity(getAppAMNodePartitionName());
if (queueAbsMaxCapPerPartition != 0) {
queueUsagePerc =
calc.divide(totalPartitionRes, report.getUsedResources(),
Resources.multiply(totalPartitionRes,
queueAbsMaxCapPerPartition)) * 100;
}
report.setQueueUsagePercentage(queueUsagePerc);
}
return report;
}
}这里的修改跟 3.0.0 的 patch 类似 3.0.001.patch，明显就是这里的逻辑到 3.0.0 都没太大变化，所以这个合并非常顺利。
当然了，这么好搞的前提，必须是你本地的 Hadoop 环境已经 ready 了，意思就是 Import 进去 IDEA，可以非常完美地执行各种单测，这样我们在合并代码的时候，就会如虎添翼，因为可以本地 debug ！关于 Hadoop 环境的问题，大家可以看看我的 blog 的其他文章，里面都有大致提到的。
