![]() See RC feeds flow & people smile at the update.Press enter when needed & follow instructions.Merge the configuration REL1_X branch to master if required (Things may crash here).(Note: All deploys outside the upgrade must stop at this point!). Switch the default branch to the new MediaWiki version for MediaWiki servers.Note that an SRE must be present at this time, as the next steps involve depooling. At the agreed time, make all wikis read only.A date and time should be arranged by the team, and notice of the upgrade should be provided at least one day in advance via a sitenotice, Twitter, Facebook, Discord and IRC.Ensure logs are checked for warnings, these may not be user visible but can easily overwhelm logging. If it is apparent that it will not be fixed anytime soon, the extension should be disabled and the upgrade should continue as planned. A reasonable time can be left for upstream to resolve the issue, or even for a member of the MW team to fix it and submit their patch upstream. If these turn out to be upstream issues, a task should be filed. If there are issues/errors, they should be investigated. Test every extension and skin and make sure that there are no issues with them.Run all the SQL patches that have been noted for betawiki.Once these steps are done, the branch for test131 can be changed to the new version of MediaWiki & config (via puppet – must be done by an SRE).If there are patches, they need to be run on every wiki using mwscript sql.php all when the upgrade is performed – make a list of these.If there are new files that are not patches (i.e., ALTER, DELETE, DROP, etc.) they need to be added either to: $wgCreateWikiSQLFiles (if the extension is globally installed) or to ManageWikiExtensions.php if the extension is not global.Check all extensions and skins and note any SQL changes (such as new files or updated files).If there are any that should potentially be blacklisted, consult SRE. Check if there are any user rights changes.Create a REL1_ branch on the config repo to apply breaking changes to.Update all extensions to the new version's corresponding branch (REL1_) on the new branch.Fetch the new version's corresponding branch (REL1_), fix any conflicts for files, and create a new branch for the repository.Obvious steps such as "read the release notes" or anything that's not an action are not mentioned, but should nonetheless be done. These steps do not all need to be done at the same time or even by the same person. New MediaWiki releases are generally done twice a year, and we try to upgrade as soon as the stable version is released however, there will be a small period in between when we do tests to make sure that everything works as expected. This page will contain every step that is to be done, both for guide purposes, but also in case users are interested in why it takes time or just how about the process in general. ![]() Normally, this can be followed, but there are a few different or extra steps that need to be taken on Miraheze, since we are a wiki farm. This page documents the process of upgrading to the next version of MediaWiki on Miraheze. An upgrade should not be done on your own, and should be planned in advance with the team ![]()
0 Comments
Leave a Reply. |