Wagtail 升级指南版本编号规则、标准升级流程与 Django/Python 兼容性矩阵【免费下载链接】wagtailA Django content management system focused on flexibility and user experience项目地址: https://gitcode.com/GitHub_Trending/wa/wagtail本文基于 Wagtail 官方升级文档docs/releases/upgrading.md编写完整覆盖功能版本/补丁版本/大版本的编号规则、逐步升级的标准流程解决弃用警告、升级前准备、执行升级、静态文件处理以及各版本对应的 Django 与 Python 兼容性矩阵并结合仓库源码剖析弃用警告的实现机制RemovedInWagtailX0Warning体系与测试运行器的--deprecation选项帮助你安全地把生产项目从一个功能版本平滑升级到最新版本。一、理解 Wagtail 的版本编号规则Wagtail 的新功能版本feature release每三个月发布一次包含新功能、改进与缺陷修复其标志是版本号中间一段递增例如 6.2 → 6.3。在此之上还有两类版本补丁版本patch release按需发布用于修复缺陷与安全漏洞标志是版本号最后一段递增例如 6.3 → 6.3.1。大版本major release偶有发布当功能版本包含编辑器界面的重大视觉变化或向后不兼容变更时版本号第一段递增例如 5.2 → 6.0。这些规则在 发布流程文档 中有更详细的表述版本以A.B或A.B.C形式编号B为 0 的发布如 6.0包含向后不兼容变更补丁版本 100% 向后兼容除非安全或数据丢失问题无法在不破坏兼容性的前提下修复。正式功能版本发布前还会至少产出一个候选版本形如A.BrcNN 表示第 N 个 release candidate。此外部分功能版本被指定为LTS长期支持版本通常每四个功能版本出现一次保证六次功能版本周期约 18 个月、含 6 个月重叠期内的安全与数据丢失修复并确保至少兼容一个 Django LTS 版本。当前仓库中的开发版本号为 8.1 alpha可在 wagtail/init.py 中看到定义# major.minor.patch.release.number # release must be one of alpha, beta, rc, or final VERSION (8, 1, 0, alpha, 0)在 Git 中每个发布都有版本标签且每个发布系列有独立的stable/A.B.x分支补丁版本从这些分支发出。二、为什么必须逐个版本升级而不是一步到位官方建议即使你的项目落后了好几个版本也要一次只升级一个功能版本。例如从 6.0 升到 6.3 时应先升级到 6.1再到 6.2最后才是 6.3。这样做有三个好处故障可定位如果升级后某处出问题你能明确知道是哪个版本引入的从而有针对性地排查弃用警告成为路标控制台输出的弃用警告deprecation warnings会提前告知你在升级到下一个版本前需要修改哪些代码数据库迁移更稳妥某些版本会做数据库 schema 变更需要通过./manage.py makemigrations在你的项目中反映出来——如果一次跨越太多 schema 变更该命令很可能失败。以下各节即为“每个目标功能版本”需要重复执行的完整步骤。三、步骤 1解决弃用警告Resolve deprecation warnings当 Wagtail 在某个版本对公开文档中的功能做向后不兼容变更时该功能在这个版本中仍然可用但使用它时会触发弃用警告。这些警告的目的是在功能于未来版本被彻底移除之前给你提前通知以便更新代码。3.1 打开警告显示Python 中弃用警告默认被静默必须显式开启。文档给出两种方式使用-Wa命令行选项等价于显示所有警告python -Wa manage.py test或通过PYTHONWARNINGS环境变量。如果你不用 Django 测试运行器还要注意确保控制台输出没有被测试框架捕获而隐藏了警告。以 pytest 为例PYTHONWARNINGSalways pytest tests --captureno在继续升级流程之前先解决当前版本Wagtail 产生的所有弃用警告。注意第三方包为了同时兼容多个 Wagtail 版本可能故意调用已弃用的 API因此你安装的第三方包发出的弃用警告不一定代表你的项目有问题。如果某个包不支持最新版本的 Wagtail可以考虑向该包提 issue 或提交 pull request。3.2 源码视角警告是如何生成的Wagtail 的弃用警告体系实现在 wagtail/utils/deprecation.py 中。以当前 8.1 alpha 开发版本为例文件定义了class RemovedInWagtail90Warning(DeprecationWarning): pass removed_in_next_version_warning RemovedInWagtail90Warning class RemovedInWagtail100Warning(PendingDeprecationWarning): pass命名规则即“将在哪个大版本移除”。DeprecationWarning是python -Wd/-Wa会显示但默认静默的类别而PendingDeprecationWarning连-Wd下都不显示因此“将在下个大版本移除”的警告被归入DeprecationWarning立即移除风险更远期移除的归入PendingDeprecationWarning。wagtail/init.py 在包导入时注册了过滤器确保removed_in_next_version_warning类别的警告总是按default策略处理def setup(): import warnings from wagtail.utils.deprecation import removed_in_next_version_warning warnings.simplefilter(default, removed_in_next_version_warning)同一个文件还提供MovedDefinitionHandler类见 wagtail/utils/deprecation.py当一个定义被移到新模块时旧位置可通过它保持可导入但访问会触发“已移动到…”的弃用警告并自动从新模块加载定义——这就是 8.0 升级注意事项中wagtail.telepath移入wagtail.admin.telepath这类迁移警告的实现机制。3.3 仓库自身如何检查弃用警告Wagtail 的测试运行器 runtests.py 内置--deprecation选项取值all/pending/imminent/none默认imminentimminent只显示 Wagtail 自身的DeprecationWarningpending追加显示PendingDeprecationWarningall则显示所有包的警告。你升级自己的项目时可以借鉴这个分级思路先只看imminent即将在下一版本移除的警告并逐一处理。四、步骤 2升级前的准备解决完弃用警告后需要完成三件事阅读下一个功能版本的发布说明。发布说明汇总在 docs/releases/index.rst。要特别关注各版本的“Upgrade considerations”升级注意事项章节——它描述了所有向后不兼容变更。以 8.0 发布说明 为例其升级注意事项按影响面分为若干小节removal of deprecated features移除 6.4–7.3 期间弃用的功能逐条列出被移除的 hook 参数、JS 函数、配置项、类与模块迁移changes affecting all projects影响所有项目的变更例如 AVIF/WebP 图片默认不再转换为 PNG并给出恢复旧行为的WAGTAILIMAGES_FORMAT_CONVERSIONS配置示例deprecation of old functionality新功能弃用例如 Azure CDN 相关依赖版本要求;changes affecting Wagtail customizations影响自定义代码的变更如register_permission_policy的独立注册要求、SnippetChooserViewSet.widget_class由实例变为类等均附带改前/改后代码对照changes to undocumented internals未公开内部接口的变更。核对 Django / Python 兼容版本表见本文第六节。你的 Django 或 Python 版本可能不满足目标 Wagtail 版本的要求需要先单独升级它们。备份数据库。在继续升级之前务必为你的数据库做一次备份。五、步骤 3执行升级对每一个要升级到的功能版本执行以下操作5.1 更新依赖声明把项目requirements.txt或等价的pyproject.toml等依赖文件中wagtail一行改为指定目标版本最新补丁版。例如升级到 6.3.x 系列wagtail6.3,6.4即“下界锁定在目标功能版本、上界排除下一个功能版本”让 pip 自动选到该系列最新的补丁版本。Wagtail 自身依赖同样采用这种区间写法例如当前仓库的 pyproject.toml 中声明了Django5.2、django-modelcluster6.5,7.0等。5.2 安装并迁移数据库pip install -r requirements.txt ./manage.py makemigrations ./manage.py migratemakemigrations用于把 Wagtail 新模型变更反映到你项目的迁移文件中Wagtail 的迁移历史本身可从 wagtail/migrations/ 目录查看例如0066_collection_management_permissions.py这类最新迁移migrate则真正把 schema 变更应用到数据库。5.3 按发布说明做代码变更按照该版本发布说明 “Upgrade considerations” 章节的指引完成必要的代码修改典型形态见上文 8.0 的例子hook 签名变化、模块移动、配置项更名等。5.4 测试与静态文件运行测试确认项目行为符合预期。静态文件Wagtail 管理端的 JavaScript/CSS 在不同版本之间可能已经变化。升级后如果管理界面出现异常行为先确认已清除浏览器缓存部署到生产服务器时务必执行./manage.py collectstatic让 Web 服务器拿到更新后的静态文件。生产环境建议启用 Django 的ManifestStaticFilesStorage配置在STORAGES[staticfiles]设置项中它会给不同版本的静态文件分配不同的 URL带内容哈希从根本上避免缓存命中旧版本文件的问题。5.5 重复对上述每个目标功能版本重复“3 → 4 → 5”三步直到到达最新版本。六、兼容的 Django / Python 版本矩阵新的功能版本通常会新增对新版 Django/Python 的支持、移除对旧版本的支持。官方建议始终将 Django 与 Python 的升级作为独立步骤与 Wagtail 升级分开进行。各 Wagtail 版本对应的 Django 与 Python 兼容版本如下*表示该支持是在补丁版本中补加的Wagtail 版本兼容 Django 版本兼容 Python 版本8.15.2, 6.0, 6.13.11, 3.12, 3.13, 3.148.05.2, 6.0, 6.13.10, 3.11, 3.12, 3.13, 3.147.4 LTS5.2, 6.03.10, 3.11, 3.12, 3.13, 3.147.34.2, 5.2, 6.03.10, 3.11, 3.12, 3.13, 3.147.24.2, 5.1, 5.2, 6.03.10, 3.11, 3.12, 3.13, 3.147.14.2, 5.1, 5.23.9, 3.10, 3.11, 3.12, 3.137.0 LTS4.2, 5.1, 5.23.9, 3.10, 3.11, 3.12, 3.136.44.2, 5.0, 5.1, 5.23.9, 3.10, 3.11, 3.12, 3.136.3 LTS4.2, 5.0, 5.1, 5.2*3.9, 3.10, 3.11, 3.12, 3.136.24.2, 5.03.8, 3.9, 3.10, 3.11, 3.126.14.2, 5.03.8, 3.9, 3.10, 3.11, 3.126.04.2, 5.03.8, 3.9, 3.10, 3.11, 3.125.2 LTS3.2, 4.1, 4.2, 5.0*3.8, 3.9, 3.10, 3.11, 3.125.13.2, 4.1, 4.23.8, 3.9, 3.10, 3.115.03.2, 4.1, 4.23.7, 3.8, 3.9, 3.10, 3.114.23.2, 4.0, 4.13.7, 3.8, 3.9, 3.10, 3.114.1 LTS3.2, 4.0, 4.13.7, 3.8, 3.9, 3.10, 3.114.03.2, 4.0, 4.13.7, 3.8, 3.9, 3.103.03.2, 4.03.7, 3.8, 3.9, 3.102.163.2, 4.03.7, 3.8, 3.9, 3.102.15 LTS3.0, 3.1, 3.23.6, 3.7, 3.8, 3.9, 3.102.143.0, 3.1, 3.23.6, 3.7, 3.8, 3.92.132.2, 3.0, 3.1, 3.23.6, 3.7, 3.8, 3.92.122.2, 3.0, 3.13.6, 3.7, 3.8, 3.92.11 LTS2.2, 3.0, 3.13.6, 3.7, 3.82.102.2, 3.0, 3.13.6, 3.7, 3.82.92.2, 3.03.5, 3.6, 3.7, 3.82.82.1, 2.2, 3.03.5, 3.6, 3.7, 3.82.7 LTS2.0, 2.1, 2.23.5, 3.6, 3.7, 3.82.62.0, 2.1, 2.23.5, 3.6, 3.72.52.0, 2.1, 2.23.4, 3.5, 3.6, 3.72.42.0, 2.13.4, 3.5, 3.6, 3.72.3 LTS1.11, 2.0, 2.13.4, 3.5, 3.62.21.11, 2.03.4, 3.5, 3.62.11.11, 2.03.4, 3.5, 3.62.01.11, 2.03.4, 3.5, 3.61.13 LTS1.8, 1.10, 1.112.7, 3.4, 3.5, 3.61.12 LTS1.8, 1.10, 1.112.7, 3.4, 3.5, 3.61.111.8, 1.10, 1.112.7, 3.4, 3.5, 3.61.101.8, 1.10, 1.112.7, 3.4, 3.5, 3.61.91.8, 1.9, 1.102.7, 3.3, 3.4, 3.51.8 LTS1.8, 1.9, 1.102.7, 3.3, 3.4, 3.51.71.8, 1.9, 1.102.7, 3.3, 3.4, 3.51.61.8, 1.9, 1.102.7, 3.3, 3.4, 3.51.51.8, 1.92.7, 3.3, 3.4, 3.51.4 LTS1.8, 1.92.7, 3.3, 3.4, 3.51.31.7, 1.8, 1.92.7, 3.3, 3.4, 3.51.21.7, 1.82.7, 3.3, 3.4, 3.51.11.7, 1.82.7, 3.3, 3.41.01.7, 1.82.7, 3.3, 3.40.8 LTS1.6, 1.72.6, 2.7, 3.2, 3.3, 3.40.71.6, 1.72.6, 2.7, 3.2, 3.3, 3.40.61.6, 1.72.6, 2.7, 3.2, 3.3, 3.40.51.62.6, 2.7, 3.2, 3.3, 3.40.41.62.6, 2.7, 3.2, 3.3, 3.40.31.62.6, 2.70.21.62.70.11.62.7矩阵与当前仓库元数据互相印证pyproject.toml 中requires-python 3.11、依赖声明Django5.2以及 Django 5.2/6.0/6.1 的分类器与表中 8.1 行完全一致。从 发布流程文档 还可以看到 Django 支持的演进规律新的 Wagtail 功能版本通常支持“上一个 Django LTS 版本及其后所有版本”若 Wagtail 版本发布时新版 Django 尚处于 beta 阶段则可能在后续补丁版本中补加支持文档举的例子是 Wagtail 5.2 在 5.2.2 补丁版中补加对 Django 5.0 的支持——正对应上表中 5.2 行的*注记。七、支持的数据库Wagtail 支持的数据库后端为PostgreSQL、MySQL、MariaDB 和 SQLite需启用 JSON1 扩展。升级前确认你的生产数据库属于此列若使用 SQLite 请确保启用了 JSON1否则 StreamField 等依赖 JSON 字段的功能无法正常工作。八、升级前检查清单把上述流程收敛成可执行清单python -Wa manage.py test或PYTHONWARNINGSalways pytest tests --captureno查看当前版本的弃用警告逐条解决阅读目标版本 发布说明 的 “Upgrade considerations” 章节核对上文兼容矩阵必要时先单独升级 Django / Python备份数据库修改requirements.txt/pyproject.toml为wagtailX.Y,X.Y1形式的区间pip install -r requirements.txt→./manage.py makemigrations→./manage.py migrate按发布说明完成代码变更并跑测试生产部署执行./manage.py collectstatic确认ManifestStaticFilesStorage已启用必要时清浏览器缓存若还落后多个功能版本回到第 1 步对下一个版本重复。附本文引用的仓库文件升级指南原文docs/releases/upgrading.md发布流程与弃用策略docs/releases/release_process.md发布说明目录含各版本 Upgrade considerationsdocs/releases/index.rst、docs/releases/8.0.md弃用警告实现wagtail/utils/deprecation.py、wagtail/init.py测试运行器弃用选项runtests.py版本与依赖声明pyproject.toml【免费下载链接】wagtailA Django content management system focused on flexibility and user experience项目地址: https://gitcode.com/GitHub_Trending/wa/wagtail创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/14 6:40:50 · 阅读 1.2k Wagtail 升级指南：版本编号规则、标准升级流程与 Django/Python 兼容性矩阵
Wagtail 升级指南版本编号规则、标准升级流程与 Django/Python 兼容性矩阵【免费下载链接】wagtailA Django content management system focused on flexibility and user experience项目地址: https://gitcode.com/GitHub_Trending/wa/wagtail本文基于 Wagtail 官方升级文档docs/releases/upgrading.md编写完整覆盖功能版本/补丁版本/大版本的编号规则、逐步升级的标准流程解决弃用警告、升级前准备、执行升级、静态文件处理以及各版本对应的 Django 与 Python 兼容性矩阵并结合仓库源码剖析弃用警告的实现机制RemovedInWagtailX0Warning体系与测试运行器的--deprecation选项帮助你安全地把生产项目从一个功能版本平滑升级到最新版本。一、理解 Wagtail 的版本编号规则Wagtail 的新功能版本feature release每三个月发布一次包含新功能、改进与缺陷修复其标志是版本号中间一段递增例如 6.2 → 6.3。在此之上还有两类版本补丁版本patch release按需发布用于修复缺陷与安全漏洞标志是版本号最后一段递增例如 6.3 → 6.3.1。大版本major release偶有发布当功能版本包含编辑器界面的重大视觉变化或向后不兼容变更时版本号第一段递增例如 5.2 → 6.0。这些规则在 发布流程文档 中有更详细的表述版本以A.B或A.B.C形式编号B为 0 的发布如 6.0包含向后不兼容变更补丁版本 100% 向后兼容除非安全或数据丢失问题无法在不破坏兼容性的前提下修复。正式功能版本发布前还会至少产出一个候选版本形如A.BrcNN 表示第 N 个 release candidate。此外部分功能版本被指定为LTS长期支持版本通常每四个功能版本出现一次保证六次功能版本周期约 18 个月、含 6 个月重叠期内的安全与数据丢失修复并确保至少兼容一个 Django LTS 版本。当前仓库中的开发版本号为 8.1 alpha可在 wagtail/init.py 中看到定义# major.minor.patch.release.number # release must be one of alpha, beta, rc, or final VERSION (8, 1, 0, alpha, 0)在 Git 中每个发布都有版本标签且每个发布系列有独立的stable/A.B.x分支补丁版本从这些分支发出。二、为什么必须逐个版本升级而不是一步到位官方建议即使你的项目落后了好几个版本也要一次只升级一个功能版本。例如从 6.0 升到 6.3 时应先升级到 6.1再到 6.2最后才是 6.3。这样做有三个好处故障可定位如果升级后某处出问题你能明确知道是哪个版本引入的从而有针对性地排查弃用警告成为路标控制台输出的弃用警告deprecation warnings会提前告知你在升级到下一个版本前需要修改哪些代码数据库迁移更稳妥某些版本会做数据库 schema 变更需要通过./manage.py makemigrations在你的项目中反映出来——如果一次跨越太多 schema 变更该命令很可能失败。以下各节即为“每个目标功能版本”需要重复执行的完整步骤。三、步骤 1解决弃用警告Resolve deprecation warnings当 Wagtail 在某个版本对公开文档中的功能做向后不兼容变更时该功能在这个版本中仍然可用但使用它时会触发弃用警告。这些警告的目的是在功能于未来版本被彻底移除之前给你提前通知以便更新代码。3.1 打开警告显示Python 中弃用警告默认被静默必须显式开启。文档给出两种方式使用-Wa命令行选项等价于显示所有警告python -Wa manage.py test或通过PYTHONWARNINGS环境变量。如果你不用 Django 测试运行器还要注意确保控制台输出没有被测试框架捕获而隐藏了警告。以 pytest 为例PYTHONWARNINGSalways pytest tests --captureno在继续升级流程之前先解决当前版本Wagtail 产生的所有弃用警告。注意第三方包为了同时兼容多个 Wagtail 版本可能故意调用已弃用的 API因此你安装的第三方包发出的弃用警告不一定代表你的项目有问题。如果某个包不支持最新版本的 Wagtail可以考虑向该包提 issue 或提交 pull request。3.2 源码视角警告是如何生成的Wagtail 的弃用警告体系实现在 wagtail/utils/deprecation.py 中。以当前 8.1 alpha 开发版本为例文件定义了class RemovedInWagtail90Warning(DeprecationWarning): pass removed_in_next_version_warning RemovedInWagtail90Warning class RemovedInWagtail100Warning(PendingDeprecationWarning): pass命名规则即“将在哪个大版本移除”。DeprecationWarning是python -Wd/-Wa会显示但默认静默的类别而PendingDeprecationWarning连-Wd下都不显示因此“将在下个大版本移除”的警告被归入DeprecationWarning立即移除风险更远期移除的归入PendingDeprecationWarning。wagtail/init.py 在包导入时注册了过滤器确保removed_in_next_version_warning类别的警告总是按default策略处理def setup(): import warnings from wagtail.utils.deprecation import removed_in_next_version_warning warnings.simplefilter(default, removed_in_next_version_warning)同一个文件还提供MovedDefinitionHandler类见 wagtail/utils/deprecation.py当一个定义被移到新模块时旧位置可通过它保持可导入但访问会触发“已移动到…”的弃用警告并自动从新模块加载定义——这就是 8.0 升级注意事项中wagtail.telepath移入wagtail.admin.telepath这类迁移警告的实现机制。3.3 仓库自身如何检查弃用警告Wagtail 的测试运行器 runtests.py 内置--deprecation选项取值all/pending/imminent/none默认imminentimminent只显示 Wagtail 自身的DeprecationWarningpending追加显示PendingDeprecationWarningall则显示所有包的警告。你升级自己的项目时可以借鉴这个分级思路先只看imminent即将在下一版本移除的警告并逐一处理。四、步骤 2升级前的准备解决完弃用警告后需要完成三件事阅读下一个功能版本的发布说明。发布说明汇总在 docs/releases/index.rst。要特别关注各版本的“Upgrade considerations”升级注意事项章节——它描述了所有向后不兼容变更。以 8.0 发布说明 为例其升级注意事项按影响面分为若干小节removal of deprecated features移除 6.4–7.3 期间弃用的功能逐条列出被移除的 hook 参数、JS 函数、配置项、类与模块迁移changes affecting all projects影响所有项目的变更例如 AVIF/WebP 图片默认不再转换为 PNG并给出恢复旧行为的WAGTAILIMAGES_FORMAT_CONVERSIONS配置示例deprecation of old functionality新功能弃用例如 Azure CDN 相关依赖版本要求;changes affecting Wagtail customizations影响自定义代码的变更如register_permission_policy的独立注册要求、SnippetChooserViewSet.widget_class由实例变为类等均附带改前/改后代码对照changes to undocumented internals未公开内部接口的变更。核对 Django / Python 兼容版本表见本文第六节。你的 Django 或 Python 版本可能不满足目标 Wagtail 版本的要求需要先单独升级它们。备份数据库。在继续升级之前务必为你的数据库做一次备份。五、步骤 3执行升级对每一个要升级到的功能版本执行以下操作5.1 更新依赖声明把项目requirements.txt或等价的pyproject.toml等依赖文件中wagtail一行改为指定目标版本最新补丁版。例如升级到 6.3.x 系列wagtail6.3,6.4即“下界锁定在目标功能版本、上界排除下一个功能版本”让 pip 自动选到该系列最新的补丁版本。Wagtail 自身依赖同样采用这种区间写法例如当前仓库的 pyproject.toml 中声明了Django5.2、django-modelcluster6.5,7.0等。5.2 安装并迁移数据库pip install -r requirements.txt ./manage.py makemigrations ./manage.py migratemakemigrations用于把 Wagtail 新模型变更反映到你项目的迁移文件中Wagtail 的迁移历史本身可从 wagtail/migrations/ 目录查看例如0066_collection_management_permissions.py这类最新迁移migrate则真正把 schema 变更应用到数据库。5.3 按发布说明做代码变更按照该版本发布说明 “Upgrade considerations” 章节的指引完成必要的代码修改典型形态见上文 8.0 的例子hook 签名变化、模块移动、配置项更名等。5.4 测试与静态文件运行测试确认项目行为符合预期。静态文件Wagtail 管理端的 JavaScript/CSS 在不同版本之间可能已经变化。升级后如果管理界面出现异常行为先确认已清除浏览器缓存部署到生产服务器时务必执行./manage.py collectstatic让 Web 服务器拿到更新后的静态文件。生产环境建议启用 Django 的ManifestStaticFilesStorage配置在STORAGES[staticfiles]设置项中它会给不同版本的静态文件分配不同的 URL带内容哈希从根本上避免缓存命中旧版本文件的问题。5.5 重复对上述每个目标功能版本重复“3 → 4 → 5”三步直到到达最新版本。六、兼容的 Django / Python 版本矩阵新的功能版本通常会新增对新版 Django/Python 的支持、移除对旧版本的支持。官方建议始终将 Django 与 Python 的升级作为独立步骤与 Wagtail 升级分开进行。各 Wagtail 版本对应的 Django 与 Python 兼容版本如下*表示该支持是在补丁版本中补加的Wagtail 版本兼容 Django 版本兼容 Python 版本8.15.2, 6.0, 6.13.11, 3.12, 3.13, 3.148.05.2, 6.0, 6.13.10, 3.11, 3.12, 3.13, 3.147.4 LTS5.2, 6.03.10, 3.11, 3.12, 3.13, 3.147.34.2, 5.2, 6.03.10, 3.11, 3.12, 3.13, 3.147.24.2, 5.1, 5.2, 6.03.10, 3.11, 3.12, 3.13, 3.147.14.2, 5.1, 5.23.9, 3.10, 3.11, 3.12, 3.137.0 LTS4.2, 5.1, 5.23.9, 3.10, 3.11, 3.12, 3.136.44.2, 5.0, 5.1, 5.23.9, 3.10, 3.11, 3.12, 3.136.3 LTS4.2, 5.0, 5.1, 5.2*3.9, 3.10, 3.11, 3.12, 3.136.24.2, 5.03.8, 3.9, 3.10, 3.11, 3.126.14.2, 5.03.8, 3.9, 3.10, 3.11, 3.126.04.2, 5.03.8, 3.9, 3.10, 3.11, 3.125.2 LTS3.2, 4.1, 4.2, 5.0*3.8, 3.9, 3.10, 3.11, 3.125.13.2, 4.1, 4.23.8, 3.9, 3.10, 3.115.03.2, 4.1, 4.23.7, 3.8, 3.9, 3.10, 3.114.23.2, 4.0, 4.13.7, 3.8, 3.9, 3.10, 3.114.1 LTS3.2, 4.0, 4.13.7, 3.8, 3.9, 3.10, 3.114.03.2, 4.0, 4.13.7, 3.8, 3.9, 3.103.03.2, 4.03.7, 3.8, 3.9, 3.102.163.2, 4.03.7, 3.8, 3.9, 3.102.15 LTS3.0, 3.1, 3.23.6, 3.7, 3.8, 3.9, 3.102.143.0, 3.1, 3.23.6, 3.7, 3.8, 3.92.132.2, 3.0, 3.1, 3.23.6, 3.7, 3.8, 3.92.122.2, 3.0, 3.13.6, 3.7, 3.8, 3.92.11 LTS2.2, 3.0, 3.13.6, 3.7, 3.82.102.2, 3.0, 3.13.6, 3.7, 3.82.92.2, 3.03.5, 3.6, 3.7, 3.82.82.1, 2.2, 3.03.5, 3.6, 3.7, 3.82.7 LTS2.0, 2.1, 2.23.5, 3.6, 3.7, 3.82.62.0, 2.1, 2.23.5, 3.6, 3.72.52.0, 2.1, 2.23.4, 3.5, 3.6, 3.72.42.0, 2.13.4, 3.5, 3.6, 3.72.3 LTS1.11, 2.0, 2.13.4, 3.5, 3.62.21.11, 2.03.4, 3.5, 3.62.11.11, 2.03.4, 3.5, 3.62.01.11, 2.03.4, 3.5, 3.61.13 LTS1.8, 1.10, 1.112.7, 3.4, 3.5, 3.61.12 LTS1.8, 1.10, 1.112.7, 3.4, 3.5, 3.61.111.8, 1.10, 1.112.7, 3.4, 3.5, 3.61.101.8, 1.10, 1.112.7, 3.4, 3.5, 3.61.91.8, 1.9, 1.102.7, 3.3, 3.4, 3.51.8 LTS1.8, 1.9, 1.102.7, 3.3, 3.4, 3.51.71.8, 1.9, 1.102.7, 3.3, 3.4, 3.51.61.8, 1.9, 1.102.7, 3.3, 3.4, 3.51.51.8, 1.92.7, 3.3, 3.4, 3.51.4 LTS1.8, 1.92.7, 3.3, 3.4, 3.51.31.7, 1.8, 1.92.7, 3.3, 3.4, 3.51.21.7, 1.82.7, 3.3, 3.4, 3.51.11.7, 1.82.7, 3.3, 3.41.01.7, 1.82.7, 3.3, 3.40.8 LTS1.6, 1.72.6, 2.7, 3.2, 3.3, 3.40.71.6, 1.72.6, 2.7, 3.2, 3.3, 3.40.61.6, 1.72.6, 2.7, 3.2, 3.3, 3.40.51.62.6, 2.7, 3.2, 3.3, 3.40.41.62.6, 2.7, 3.2, 3.3, 3.40.31.62.6, 2.70.21.62.70.11.62.7矩阵与当前仓库元数据互相印证pyproject.toml 中requires-python 3.11、依赖声明Django5.2以及 Django 5.2/6.0/6.1 的分类器与表中 8.1 行完全一致。从 发布流程文档 还可以看到 Django 支持的演进规律新的 Wagtail 功能版本通常支持“上一个 Django LTS 版本及其后所有版本”若 Wagtail 版本发布时新版 Django 尚处于 beta 阶段则可能在后续补丁版本中补加支持文档举的例子是 Wagtail 5.2 在 5.2.2 补丁版中补加对 Django 5.0 的支持——正对应上表中 5.2 行的*注记。七、支持的数据库Wagtail 支持的数据库后端为PostgreSQL、MySQL、MariaDB 和 SQLite需启用 JSON1 扩展。升级前确认你的生产数据库属于此列若使用 SQLite 请确保启用了 JSON1否则 StreamField 等依赖 JSON 字段的功能无法正常工作。八、升级前检查清单把上述流程收敛成可执行清单python -Wa manage.py test或PYTHONWARNINGSalways pytest tests --captureno查看当前版本的弃用警告逐条解决阅读目标版本 发布说明 的 “Upgrade considerations” 章节核对上文兼容矩阵必要时先单独升级 Django / Python备份数据库修改requirements.txt/pyproject.toml为wagtailX.Y,X.Y1形式的区间pip install -r requirements.txt→./manage.py makemigrations→./manage.py migrate按发布说明完成代码变更并跑测试生产部署执行./manage.py collectstatic确认ManifestStaticFilesStorage已启用必要时清浏览器缓存若还落后多个功能版本回到第 1 步对下一个版本重复。附本文引用的仓库文件升级指南原文docs/releases/upgrading.md发布流程与弃用策略docs/releases/release_process.md发布说明目录含各版本 Upgrade considerationsdocs/releases/index.rst、docs/releases/8.0.md弃用警告实现wagtail/utils/deprecation.py、wagtail/init.py测试运行器弃用选项runtests.py版本与依赖声明pyproject.toml【免费下载链接】wagtailA Django content management system focused on flexibility and user experience项目地址: https://gitcode.com/GitHub_Trending/wa/wagtail创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考