Chromium的开发者非常用功地把新功能新特性尽可能快的引入新版本，因此，造成像CEF这样的依赖于它的项目也必须经常更新版本，更新可能会很复杂，必须非常小心的处理，以避免导入新的bug和破坏。以下是将CEF使用的Chromium版本更新到新版的处理步骤。

1. 更新到最新版的“绿”Chromium版本，查看Chromium build waterfall，选择最新的所有windows编译与测试都是绿色的版本.

2. 创建一个新老Chromium版本的对比

svn diff -r oldrev:newrev > diff_oldrev-newrev.txt

以下文件的变化需要被评估:

chrome/browser/net/sqlite_persistent_cookie_store.* content/browser/in_process_webkit/* third_party/WebKit/Source/WebKit/chromium/public/* webkit/glue/webpreferences.h (watch for new WebKit features that may need to be enabled) webkit/support/simple_database_system.* webkit/tools/test_shell/*

这可以用于帮助你识别哪些地方发生了变更，CEF开始于一个定制的test_shell版本，有很多文件仍存在有1对1的关系。

3. 对CEF做出必要的修改，编译（必须先清除）并修复所有失败。

4. 运行大量的CEF测试，确保一切正常，这一步有望在将来实现自动化。

查看 CEF Build Bot 日志，可以提供更新后查找错误的感觉。大多数情况下（90%），失败是因为重命名、少量的代码重构或者项目名称、位置变化造成的,剩下的10%需要CEF做出重大调整，通常是因为不断重构成webkit/api的webkit/glue造成的。如果你发现Chromium的变更影响了CEF需要的功能，而你又不能在合理的修改CEF的情况下绕开这个问题，那么你应当与Chromium团队协作处理这个问题。

1. 标识哪一版本影响了CEF的功能，并确认你已经理解了为什么要做出这些修改。

2. 向chromium-dev邮件列表提交一条信息，说明变更为什么影响了CEF，并且提供其它信息、建义修复CEF和Chromium。

3. 之后，Chromium开发者创建了条代码重审事件，并且提供修复与对应的开发者。

4. 更进代码评审。

CEF也提供被丁的功能，但是这应该作为最后的手段，或者你认为代码重审需要很长时间的权宜之计，最好的方式应该是由Chromium接收你的变更请求到Chromium Trunk中。