如果你关注MediaWiki并且在网上浏览过很多的维基站，那么有可能你会注意到其中一些知名站点使用的还是老古董的MediaWiki版本（比如充满古早味的MBA智库百科）。通常来说，这些站点不升级都是有其原因的（除去没人维护），常见的因素包括：

• 对目前运行的版本感到满意，觉得没必要升级
• 担心破坏现有功能，比如新版本不支持某些皮肤（skin）或扩展（extension）
• 对潜在破坏性的顾虑，比如新版本的代码BUG较多、扩展的兼容性不佳等

这些顾虑和担忧并不是空穴来风。对于开源软件来说，特别是像MediaWiki这种不断发展，在方法上弃旧迎新，并且时不时地重构代码的系统来说，确实要特别注意。你得考虑新版本与其他软件或者服务器配置的兼容性（比如PHP版本）、代码中潜在的重大变更，以及是否具备执行升级和解决潜在问题所需要的专业知识或者具备该能力的专家。
当然一成不变地使用旧版本，哪怕公众或站长对其满意，都可能存在一定的安全隐患，毕竟漏洞无处不在，别有用心的人也无处不在。
考虑到上述因素和条件限制，你要做的就是根据自己维基站点的用途、规模、关键任务等制定一个成熟的升级方案。

MediaWiki的升级策略

目前，MediaWiki的发行政策主要包括三种不同类型：

• 次要版本——包括安全补丁、向后移植的消息翻译和一般错误修复。次要版本的示例包括 MediaWiki 1.39.4 和 MediaWiki 1.39.5。
• 主要版本——大约每六个月发布一次。这些版本可能包括需要数据库结构升级或配置审查的更改，并且它们有可能终止过时的扩展。主要版本的示例包括 MediaWiki 1.39 或 MediaWiki 1.40。
• 长期支持版本（LTS）——每一两年就会发布一次的主要版本，LTS 支持有一年的重叠。例如，1.35 LTS 于 2023 年 11 月（即 1.39 LTS 发布一年后）终止生命周期。长期支持版本在整个生命周期内都会获得安全性和错误修复。

MediaWiki使用插件（plugin）来增强其功能，通常称为“扩展（extension）”。虽然有些是由维基媒体基金会官方支持和维护的，但其他一些是由不同程度的个人或组织开发和维护的。这些贡献者可能很忙，不太活跃，或者专注于不同的优先事项。因此，扩展有可能被放弃、过时、偏离MediaWiki核心代码或被更新的替代方案取代。
如果你使用的是不带扩展程序或带有默认的捆绑扩展程序集的普通MediaWiki安装，则采用对次要版本和主要版本进行定期更新的策略可能是合适的。
值得注意的是，从1.36版本开始，MediaWiki仅支持从两个最新的LTS版本的升级。如果你是低于1.35版的旧版本，那么在升级时需要分多个步骤进行——也就是先升级到1.35，然后再从1.35升级到你希望的高版本。就像上面提到的，如果你能接受次要版本升级的，那么建议在每次新的次要版本或主要版本可用时都进行升级，前提是要遵守下面所提到的最佳实践。
MediaWiki是为支持维基百科（Wikipedia）而开发的，其开箱即用的功能可能与你的特定维基使用实例所需的功能有所不同。许多MediaWiki站点的所有者希望定制外观和功能来满足他们的独特需求。由于MediaWiki的灵活性和可扩展性，它可以通过社区维护或定制的皮肤和扩展来实现。
发布扩展的工作流程独立于核心版本运行。每个扩展都可以建立自己的兼容性策略。一些扩展致力于保持与主要版本的向后兼容性，而其他扩展则可能与核心主要版本的版本保持一致。扩展维护者通常会优先考虑与LTS版本的兼容性。实际上，每六个月发布一次主要版本通常会引入一些更改，这些更改可能会破坏你正在使用的扩展。上游开发人员解决问题可能会大大推迟升级到主要版本的过程，使其成为一项繁琐的任务。
如果你对MediaWiki安装进行了自定义，请完整记录它们——包括对皮肤、模板或软件其他方面的任何更改。它将帮助你根据需要修改自定义代码，以与 MediaWiki代码库中的更改保持一致。
如果你正在管理MediaWiki的自定义实例，建议遵守LTS发布周期并跳过非LTS的主要升级。相反，应专注于将点向后移植应用于当前使用的LTS版本。这种方法保证了生产环境的安全性和稳定性，提供了有效规划和执行下一次LTS升级的机会。LTS版本重叠大约一年，你有充足的时间来解决扩展兼容性问题。
当然，你可以根据维基站点的任务、投入和预算自由选择任何其他策略。

用于升级的分发系统

有各种各样的分发系统可以提供对MediaWiki核心和扩展的升级。在启动基于mediawiki的项目时，关于最合适的分发系统的决定是至关重要的。

1. 安装包

MediaWiki核心和大多数扩展的默认方法。你可以从官方站点或使用扩展分发程序或通过命令行下载zip或tar归档文件：

wget https://releases.wikimedia.org/mediawiki/1.40/mediawiki-1.40.1.tar.gz

在该示例中，升级过程包括提取存档内容和替换目标目录。
它看起来很简单，可以使用FTP客户端来完成，但请不要忘记，使用Web或命令行界面运行数据库升级后，MediaWiki可能需要运行维护脚本（1.39版以下运行：php maintenance/update.php，1.40版以后运行：php maintenance/run.php update.php）或从命令行更新Composer管理的依赖项。

2. Git

Git是一种分布式版本控制系统，通常用于在软件开发过程中跟踪源代码的更改。MediaWiki核心和大多数扩展将其代码存储在基于git的存储库中。
对于正在积极开发或定制的MediaWiki实例，建议从Git下载。使用单个命令，你可以获得完整的分支树和提交，或者拉出确切的分支或提交。例如，要安装 MediaWiki 1.39，请运行：

git clone https://gerrit.wikimedia.org/r/mediawiki/core.git --branch REL1_39 mediawiki

如果是MediaWiki 1.39.5这样的小幅升级也非常简单：

# 获取最新的代码
git pull 

# 在给定标签处打开存储库
git checkout 1.39.5 

# 升级捆绑的扩展或作为子模块添加的其他扩展
git submodule update --init

更新从Git克隆的各个扩展时也适用类似的过程，只需选择相应的分支或标签即可签出。

# 列出所有可用分支
gitbranch -a 

# 列出所有可用标签
git tag –list 

# 升级用于Mediawiki 1.39的ContactPage扩展
cd extensions/ContactPage 
git checkout REL1_39

与许多命令行工具一样，通过Git进行升级既简单又强大。然而，他们需要理解Git基础知识并熟悉MediaWiki管理和维护工作流程。
请注意，当你使用扩展分发器将扩展作为存档获取时，必要的依赖项会随存档一起提供。当你从git获取软件时，MediaWiki 核心和某些扩展可能需要Composer（PHP 的依赖项管理器）来安装依赖库和包。

安装和更新MediaWiki以及具有由Composer管理的依赖项的扩展将需要运行：

composer update --no-dev

当你决定使用给定扩展时，请检查mediawiki.org上的文档页面，以了解其兼容性政策、强制使用Composer涉及的数据库更改。

更多关于git的升级内容也可以参考本站的其他文章。

3.Docker

Docker是一个旨在提供标准化方式来打包和分发应用程序的平台，确保不同环境之间的一致性。你可以将Docker视为已优化运行MediaWiki以及Docker镜像中包含的任何扩展的现成可用环境。
WikiTeq维护Taqasta – 一个功能齐全的MediaWiki堆栈，可在生产环境中轻松部署企业级MediaWiki。Taqasta捆绑了100多个经过充分测试的扩展。要升级整个堆栈，你只需更改“docker-compose.yml”文件中的镜像标签：

- image: ghcr.io/wikiteq/taqasta:1.35.8
+ image: ghcr.io/wikiteq/taqasta:1.39.5

几分钟后，你的MediaWiki和扩展将升级到请求的版本。基于Docker的部署可处理各种管理和维护任务，为那些寻求以更低的成本和最少的麻烦寻求稳定、高效的环境的人提供便捷的解决方案。

MediaWiki升级的最佳实践

查看系统要求

确认你的服务器环境满足新版本MediaWiki的系统要求——包括PHP、MySQL或其他数据库要求。请注意，如果你使用像Taqasta这样的Docker镜像，它已经附带了运行MediaWiki所需的正确版本的PHP、MySQL和其他软件。

监控资源使用情况

评估MediaWiki新版本的资源需求，以确保你的服务器能够处理增加的需求。这包括CPU、内存和磁盘空间的注意事项。

查看发行说明

仔细阅读你要升级到的版本的发行说明。这包括有关新功能、更改以及与现有扩展或自定义代码的任何潜在不兼容性的信息。
请注意新版本中已弃用或删除的任何功能。相应地调整你的自定义代码或配置，以避免升级期间或升级后出现问题。
检查LocalSettings.php文件中是否有任何已弃用的设置或配置选项的更改。相应地更新配置文件。

检查扩展和皮肤的兼容性

验证你安装的扩展是否与新版的MediaWiki兼容。某些扩展可能需要更新或替换才能与最新版本一起使用。如果你使用第三方扩展或皮肤，请确保它们已更新到与新版MediaWiki兼容的版本。检查官方扩展和皮肤页面以获取兼容性信息。

为停机做好准备

重大升级可能需要你的wiki站点停机一段时间。请制定升级计划（选择合适的升级时间以最大程度地减少中断）并将其传达给你的用户。
准备回滚计划，以防升级遇到不可预见的问题。了解如何快速恢复到以前的版本有助于最大限度地减少停机时间。

清空待处理的作业

出于性能原因，数据库中的某些操作被延迟，并由作业队列管理。 这些作业存储在数据库中，并包含有关应执行的操作的信息参数。 强烈建议在升级Wiki前运行这些待处理的作业，以避免这些参数在新版本中发生变化而失败。 在执行升级前，可使用runJobs.php运行所有挂起的作业并清除队列。

备份数据

在开始升级之前，请务必创建MediaWiki数据库和文件的全面备份。这可确保你在出现任何问题时可以恢复到之前的状态。

在临时环境中进行测试

设置生产环境的临时镜像或测试镜像。在将更改应用到实时站点之前，在此环境中测试升级过程、扩展和自定义。

安排升级

选择合适的时间进行升级，考虑对用户影响最小。记得向你的用户传达维护计划。

无论你采用何种策略，请考虑遵守上述规则和方法，以增加成功更新MediaWiki的可能性，同时尽量减少对wiki功能的干扰。

如需更多帮助，也可以参考官方文档。

本文翻译自https://wikiteq.com/post/mediawiki-upgrade-policy，并作了适当修改。