简介
本指南列出升级到新版本时，现有 Yocto Project 配置可能需要适应的不向后兼容变更。
如果跨越多个版本升级，需要依次阅读从原版本的下一版本直到目标新版本的各节。
通用迁移注意事项
有些注意事项并不局限于特定的 Yocto Project 版本。 本节介绍迁移到任何新版本时都应考虑的信息。
处理定制配方：
迁移到新的 Yocto Project 元数据后，如果直接复制含有定制内容的旧配方， 并期望它们继续工作，可能会遇到问题。例如，层中的配方可能是从早期版本复制的 核心配方的定制版本，而不是通过追加文件进行定制。迁移到较新的 Yocto Project 版本时，元数据（例如该配方使用的包含文件）可能发生了使构建失效的变化。 例如，包含文件移除了某个函数，而定制配方仍试图调用该函数。
可以将配方中的所有定制内容向前移植，使其适用于新版本。但这并非最佳方案， 因为每次新版本中出现会引起问题的变更时，都需要重复这一过程。
在可行的情况下，更好的方法是使用追加文件（
*.bbappend）记录对配方的定制。 这样可以将变更与主配方隔离，使其更易于管理。不过，有时追加文件并不适用， 例如在另一个层中引入配方的较新或较旧版本。更新追加文件：
追加文件（
.bbappend）通常仅包含定制内容，因此往往不需要为新版本调整。 但是，如果追加文件针对配方的特定版本（即名称未使用 % 通配符），而被追加的 配方版本已经改变，那么至少需要重命名追加文件，使其与配方文件的名称匹配。 追加文件与对应配方文件（.bb）不匹配会在解析期间触发错误。根据追加文件所应用的定制类型，升级时还可能出现其他不兼容问题。 例如，追加文件应用了一个补丁，而被追加的配方更新到较新版本后，该补丁可能 无法再应用。如果仍然需要该补丁，就必须修改补丁文件，使其可以应用。
小技巧
运行以下命令可以列出配置中使用的所有追加文件：
bitbake-layers show-appends
检查镜像／SDK 变更：
若要检查迁移对镜像／SDK 的影响（例如新增或移除的软件包、文件以及大小变化）， 可以使用 buildhistory 类。具体步骤如下：
在迁移前启用 buildhistory
执行一次迁移前的构建
保存 buildhistory 输出（位置由 BUILDHISTORY_DIR 指定），并确保后续构建仍保留这些输出。具体做法取决于构建方式：如果始终在 同一工作站的同一个 Build Directory 中构建，可能只需避免删除 buildhistory 输出目录。流水线构建可能需要更复杂的处理。
迁移前，在 buildhistory 输出中设置一个 Git 标签 （该输出本身是 Git 仓库），以便查找迁移前构建的提交，因为迁移过程中 可能需要执行多次构建。
执行迁移
执行构建
使用
git diff或buildhistory-diff检查 buildhistory 输出中先前设置的标签与 HEAD 之间的变化。
使用 buildhistory 的更多信息见 使用 buildhistory 保持构建输出质量。