⚓ T259771 RFC: Drop support for older database upgrades

⚓ T259771 RFC: Drop support for older database upgrades
Page Menu
Phabricator
Create Task
Maniphest
T259771
RFC: Drop support for older database upgrades
Closed, Resolved
Public
Actions
Edit Task
Edit Related Tasks...
Create Subtask
Edit Parent Tasks
Edit Subtasks
Merge Duplicates In
Close As Duplicate
Edit Related Objects...
Edit Commits
Edit Mocks
Mute Notifications
Protect as security issue
Assigned To
Ladsgroup
Authored By
Ladsgroup
Aug 6 2020, 1:48 AM
2020-08-06 01:48:59 (UTC+0)
Tags
Platform Engineering
(Feature Requests to Review)
MediaWiki-Stakeholders-Group
(Needs Discussion)
TechCom-RFC (TechCom-RFC-Closed)
(Implemented)
User-Ladsgroup
(Done)
MW-1.37-notes (1.37.0-wmf.1; 2021-04-13)
MW-1.36-notes
(Backlog)
Referenced Files
None
Subscribers
Aklapper
Akuckartz
Bawolff
Daimona
daniel
DannyS712
Emufarmers
View All 21 Subscribers
Description
Affected components: Mediawiki core
Engineer(s) or team for initial implementation:
@Ladsgroup
(In volunteer capacity)
Code steward: Platform team
Motivation
Currently, MysqlUpdater class on master has (at least on paper) support for upgrading from
1.2
(Released on 2004-05-24, which predates birth of some of our volunteer devs) to 1.35 (hasn't released yet) and it seems there is no plan to stop it and it will continue forever.
As the result:
Number of database checks in MySQL is reaching 500 and size of the class to 1,500 lines of code.
The archive of sql patches (directory of
maintenance/archives/
) is really large and unorganized
In every update.php run, the system has to run all of these checks (
updatelog
stores that some of them are done but it's not sql checks and it's only maintenance script runs as far as I see in my localhost)
Due to lots of reasons, update.php can never be ran in production but it manages to sneak in and get ran and cause outages:
T157651: sql.php must not run LoadExtensionSchemaUpdates
. This means reducing the probability of causing issues in case this kind of problem happen again would be nice.
Keeping ability to upgrade from any point in time makes schema change logic quite complex:
You can't reintroduce an index (with different columns for example) and it has to have a different name, otherwise the update.php in every run (on master) removes the index and re-add it again. Same goes with changing field data type twice, if you change it from blob to varchar and a couple years later to varbinary, the system on master sees that the field type is not varchar, thinks it's blob, change it to varchar, and then the next check sees that it's not varbinary, and turns it to varbinary and it happens in every update.php run. You might argue that we can remove the first schema change but what if one of the updates in between depends on this certain data type?
If you remove a table, you need to remove all updates related to it, otherwise the update logic will break (like
T230317: Error: 1146 Table 'valid_tag' doesn't exist when upgrading from an ancient MediaWiki version
This complex logic was one of reasons behind one of our biggest outages when a really important table got dropped because Wikibase assumed due to lack of
wb_terms
table which was meant to be dropped from the code soon, the system is upgrading from a version that's 8 years old (predating
wb_terms
) so dropped several tables to rebuild them. i.e. Wikibase mistook the future with the far past:
T249565: Wikidata's wb_items_per_site table has suddenly disappeared, creating DBQueryErrors on page views
This logic never worked properly from old versions anyway and it's famous in third party users that for big jumps and large databases, it's unreliable. They usually upgrade from one LTS to another multiple times instead and given that we have VCS, it makes sense.
Due this complex logic, properly writing test for it is hard, there are some snapshots (in sqlite) that build the system, run upgrade on it and check if it matches with the current system but it's pretty limited and doesn't cover upgrade from all releases.
The complex logic is not documented and stored as institutional knowledge with low bus factor which lots of devs have to explain and repeat for every new person doing a schema change for the first time (
here's an example
Technically upgrading from 1.2 is impossible because the MySQL version that mediawiki 1.2 needs is so different from 1.35 that MySQL upgrade (with lots of data) would be non-trivial
Requirements
No current functionality for upgrading from an LTS to another should break
The developer productivity and onboarding cost of doing schema changes in core and extensions should improve.
The *Updater classes should stop growing non-stop
Exploration
Proposal:
On master, only support upgrading from the last LTS release that's not EOL'd yet (basically meaning two LTS releases). Remove all of old updates and their
.sql
files and make it clear in
RELEASE-NOTES
(add a dedicated section that upgrades from which releases are supported).
The only downsides with proposal:
It would be harder for people to upgrade from really really old versions and need to do it in jumps but update.php is unreliable in that regard anyway.
The current archives of
.sql
files is actually a good library to find the most similar alter table to copy-paste, specially for DBMS engines that are different from the ones the dev is familiar with (like Postgres or Oracle to me). But this will be fully addressed with abstract schema changes (
T191231: RFC: Abstract schemas and schema changes
) which will come in the next couple of months.
Details
Related Changes in Gerrit:
Subject
Repo
Branch
Lines +/-
RELEASE-NOTES-1.36: Re-work UPGRADE reference
mediawiki/core
REL1_36
+2
-2
RELEASE-NOTES-1.3{6,7}: Re-work UPGRADE reference
mediawiki/core
master
+4
-4
Rework sqlite schema changes tests
mediawiki/core
master
+1 K
-5 K
Fail update if bot_passwords doesn't exist
mediawiki/core
master
+17
-189
Customize query in gerrit
Related Objects
Search...
Task Graph
Mentions
Status
Subtype
Assigned
Task
Resolved
None
T272199
Drop unsupported upgrade patch files and logic
Resolved
Daimona
T280012
Drop support for old database upgrades from AbuseFilter
Resolved
Ladsgroup
T259771
RFC: Drop support for older database upgrades
Mentioned In
T378984: Drop support for MediaWiki <= 1.30
T331608: Update error 1.39.1->1.39.2: "Can't DROP 'user_timestamp'; check that column/key exists"
T360421: Remove 1.34 and before schema updates from GlobalBlocking
T278033: Upgrade testing-Wikimini from MediaWiki 1.28.0 to 1.39
T326071: Upgrade from 1.31.2 to 1.39 results in pages no longer being usable with "The revision #0 of the page named "x" does not exist." error
T166010: The Great Namespaceization Effort
T325706: Work out what to do with ConcatenatedGzipHistoryBlob in our future
T314909: Running update.php with an empty database should reinstall the tables, throws "Can not upgrade from versions older than 1.31" instead
T313164: 1.38 installer talks about extensions migrated into core in MediaWiki version 1.14
T303684: Remove unused configuration global $wgLegacySchemaConversion
T247220: Feature Request: data format for portability between wikibase instances
T273080: Stop managing both interwiki.list and interwiki.sql
T272199: Drop unsupported upgrade patch files and logic
T120216: Installation does not work for MW 1.26+ due to removal of hitcounter table
T205094: Investigate and restructure SQL directory, and use new MediaWiki abstract schema change features
Mentioned Here
T272199: Drop unsupported upgrade patch files and logic
T157651: sql.php must not run LoadExtensionSchemaUpdates
T191231: RFC: Abstract schemas and schema changes
T230317: Error: 1146 Table 'valid_tag' doesn't exist when upgrading from an ancient MediaWiki version
T249565: Wikidata's wb_items_per_site table has suddenly disappeared, creating DBQueryErrors on page views
Event Timeline
There are a very large number of changes, so older changes are hidden.
Show Older Changes
Michael
awarded a token.
Sep 16 2020, 8:01 AM
2020-09-16 08:01:07 (UTC+0)
Michael
subscribed.
Krinkle
moved this task from
P2: Resource
to
P3: Explore
on the
TechCom-RFC
board.
Sep 18 2020, 2:59 AM
2020-09-18 02:59:29 (UTC+0)
Comment Actions
@Ladsgroup
Looks like this is ready for
Phase 3
, moving it on your behalf.
Ladsgroup
added a comment.
Sep 18 2020, 7:55 AM
2020-09-18 07:55:37 (UTC+0)
Comment Actions
In
T259771#6473335
@Krinkle
wrote:
@Ladsgroup
Looks like this is ready for
Phase 3
, moving it on your behalf.
Thanks!
RazeSoldier
subscribed.
Oct 9 2020, 4:29 AM
2020-10-09 04:29:20 (UTC+0)
Nikerabbit
subscribed.
Oct 9 2020, 8:04 AM
2020-10-09 08:04:21 (UTC+0)
Kghbln
subscribed.
Oct 9 2020, 8:54 AM
2020-10-09 08:54:35 (UTC+0)
Kghbln
added a comment.
Oct 9 2020, 9:03 AM
2020-10-09 09:03:52 (UTC+0)
Comment Actions
I agree with
T259771#6419957
and can confirm this from field experience. See here for a rough
overview on WikiApiary
Prod
awarded a token.
Oct 9 2020, 6:07 PM
2020-10-09 18:07:59 (UTC+0)
Prod
subscribed.
Ladsgroup
added a comment.
Oct 9 2020, 6:57 PM
2020-10-09 18:57:26 (UTC+0)
Comment Actions
@Bawolff
@Kghbln
Thanks for the information. Do you think upgrading from 1.16 directly is a must or it's okay if they upgrade to 1.31 first and then to 1.35 (and above)? 1.16 was released around ten years ago.
Regarding how to determine on what version we are upgrading from, that's really complicated, we don't store the version in the database (and even if we fix it, that's not going to affect old releases) and if someone is upgrading, they have removed the old file :/ We can introduce an option to upgrade.php to take the previous version and check against it and assume it's the current release if not set. Does that sound good?
Mainframe98
awarded a token.
Oct 11 2020, 7:45 AM
2020-10-11 07:45:08 (UTC+0)
Ladsgroup
added a comment.
Nov 9 2020, 7:16 AM
2020-11-09 07:16:30 (UTC+0)
Comment Actions
Can we move forward with this?
daniel
subscribed.
Edited
Nov 19 2020, 11:59 AM
2020-11-19 11:59:04 (UTC+0)
Comment Actions
We reviewed this in yesterday's TechCom meeting. The following questions have come up:
We need a way to detect and safely abort if someone tries to update from a version that is too old. So we have to somehow somewhere record in the database what version we are on. Maybe a simple revision number would be sufficient, but maybe we want something more fine grained. Maybe we can use update_log, maybe not. This needs a little more thought.
Who owns this policy? Presumably the
Platform Engineering
team would need to champion it.
We may want to discuss again what the limit is - two LTS releases, or maybe three? Do we need to reach out once more to potentially affected third parties?
For the RFC to go on last call, it should propose a specific wording of a policy.
Ladsgroup
added a comment.
Edited
Nov 19 2020, 10:11 PM
2020-11-19 22:11:59 (UTC+0)
Comment Actions
In
T259771#6633343
@daniel
wrote:
We reviewed this in yesterday's TechCom meeting. The following questions have come up:
We need a way to detect and safely abort if someone tries to update from a version that is too old. So we have to somehow somewhere record in the database what version we are on. Maybe a simple revision number would be sufficient, but maybe we want something more fine grained. Maybe we can use update_log, maybe not. This needs a little more thought.
The problem is that it's impossible to implement, if we add something that leaves a marker in database, it's still can't be propagated to previous installations using EOL'ed releases in the wild. I have two ideas and have no preference which way to go :
Adding an optional argument to update.php and the maintainer providing that. So for example:
php maintenance/update.php --from-version=1.12
would abort on 1.36. Given the backward compatibility, I think if not applied, we should assume it's updating from within a release
Or, use the database implicit markers, for example table
hitcounter
was dropped in 1.26, if such table exists, we would abort the update. We need define such marker in every release.
Who owns this policy? Presumably the
Platform Engineering
team would need to champion it.
We may want to discuss again what the limit is - two LTS releases, or maybe three? Do we need to reach out once more to potentially affected third parties?
I asked several places, honestly I ran out of places to reach out to.
For the RFC to go on last call, it should propose a specific wording of a policy.
"MediaWiki doesn't support upgrading from versions predating two LTS releases (for example, if LTS releases are 1.35, 1.31, 1.27, ... upgrading from 1.30 and below to anything above 1.35 is not supported). If you want to upgrade from an old version, you can do it with jumps to multiple LTS releases (for example, for upgrading from 1.27 to 1.36, upgrade to 1.31 first, then 1.36)"
(Feel free to edit mercilessly)
daniel
moved this task from
P3: Explore
to
P4: Tune
on the
TechCom-RFC
board.
Nov 19 2020, 11:03 PM
2020-11-19 23:03:36 (UTC+0)
Comment Actions
We just discussed this in the
Platform Engineering
(PET) technical planning meeting. People in the meeting agreed with the general idea, though there was some discussion over whether it should be two LTS releases or three. PET can be the owner of the new policy, and champion this proposal.
Or, use the database implicit markers, for example table hitcounter was dropped in 1.26, if such table exists, we would abort the update. We need define such marker in every release.
According to the discussion in the meeting we just had, this would be the way to go for past versions. For future updates, we should write the major version to the database somewhere.
Provided this RFC is approved, PET could take on the work needed on the installer, but we are trying to be more focus in our work and avoid distractions. which means that new tasks coming up go to the end of the queue, and it may be a while until we get to them.
@Ladsgroup
, if you would write the code for deciding whether an update is supported or not, that would probably help to speed things along.
I think with this, this RFC is ready for phase 4 (tune).
Ladsgroup
added a comment.
Nov 20 2020, 12:03 AM
2020-11-20 00:03:58 (UTC+0)
Comment Actions
In
T259771#6635238
@daniel
wrote:
We just discussed this in the
Platform Engineering
(PET) technical planning meeting. People in the meeting agreed with the general idea, though there was some discussion over whether it should be two LTS releases or three. PET can be the owner of the new policy, and champion this proposal.
I'm fine with any reasonable number, two or three, etc.
Or, use the database implicit markers, for example table hitcounter was dropped in 1.26, if such table exists, we would abort the update. We need define such marker in every release.
According to the discussion in the meeting we just had, this would be the way to go for past versions. For future updates, we should write the major version to the database somewhere.
Provided this RFC is approved, PET could take on the work needed on the installer, but we are trying to be more focus in our work and avoid distractions. which means that new tasks coming up go to the end of the queue, and it may be a while until we get to them.
@Ladsgroup
, if you would write the code for deciding whether an update is supported or not, that would probably help to speed things along.
I can write the code that take the implicit marker and abort the update (more in a rather hacky way I assume given that it'll be removed later) but I don't think I have the capacity to write the part about explicit markers.
I think with this, this RFC is ready for phase 4 (tune).
\o/
Ammarpad
awarded a token.
Nov 20 2020, 2:01 AM
2020-11-20 02:01:27 (UTC+0)
daniel
added a comment.
Nov 20 2020, 9:00 AM
2020-11-20 09:00:48 (UTC+0)
Comment Actions
In
T259771#6635398
@Ladsgroup
wrote:
I can write the code that take the implicit marker and abort the update (more in a rather hacky way I assume given that it'll be removed later) but I don't think I have the capacity to write the part about explicit markers.
Excellent, thank you!
For explicit markers, perhaps it would be sufficient to write the major version into updatelog, e.g. ul_key = 'MW-1.36'.
DannyS712
added a comment.
Nov 20 2020, 3:33 PM
2020-11-20 15:33:25 (UTC+0)
Comment Actions
In
T259771#6636013
@daniel
wrote:
In
T259771#6635398
@Ladsgroup
wrote:
I can write the code that take the implicit marker and abort the update (more in a rather hacky way I assume given that it'll be removed later) but I don't think I have the capacity to write the part about explicit markers.
Excellent, thank you!
For explicit markers, perhaps it would be sufficient to write the major version into updatelog, e.g. ul_key = 'MW-1.36'.
Won't that result in a new key each time? Would it be possible to use a single key, and just change the value?
Prod
mentioned this in
T120216: Installation does not work for MW 1.26+ due to removal of hitcounter table
Dec 6 2020, 7:57 AM
2020-12-06 07:57:09 (UTC+0)
Ladsgroup
added a comment.
Dec 12 2020, 1:43 PM
2020-12-12 13:43:14 (UTC+0)
Comment Actions
What needs to be done to move this forward? The
maintenance/archives/
directory now has 315 files (and counting). I make a patch to be merged for 1.36.
gerritbot
added a comment.
Dec 12 2020, 1:52 PM
2020-12-12 13:52:03 (UTC+0)
Comment Actions
Change 648576 had a related patch set uploaded (by Ladsgroup; owner: Ladsgroup):
[mediawiki/core@master] Fail update if hitcounter exists
gerritbot
added a project:
Patch-For-Review
Dec 12 2020, 1:52 PM
2020-12-12 13:52:04 (UTC+0)
Ladsgroup
added a comment.
Dec 12 2020, 1:54 PM
2020-12-12 13:54:40 (UTC+0)
Comment Actions
This is for three LTS releases ^
Tgr
added a comment.
Dec 14 2020, 3:45 AM
2020-12-14 03:45:27 (UTC+0)
Comment Actions
TBH I don't think the reasons in the task summary are convincing. If the archive files are annoying, we can just move them elsewhere. Column conflicts are indeed a problem, but this is a half-fix, and we should focus on a proper fix instead - just start using
updatelog
consistently for all schema changes, and backfill old values. (In other words, there should be a table which contains all the patchfiles MediaWiki ever had, and which of them had been applied, or "preapplied" in that the wiki was installed with a schema already including that patch.)
Anecdotally, I do see people trying to upgrade from 1.16 regularly. (Which of course would still be possible after this change, but more cumbersome...)
Probably the most inherently fragile part of upgrades is whether maintenance scripts work with an arbitrarily old schema (hello NameTableStore). But I don't think we'd avoid that problem by restricting to 2-3 LTS releases (ie. 4-6 years).
daniel
added a comment.
Edited
Dec 14 2020, 11:01 AM
2020-12-14 11:01:49 (UTC+0)
Comment Actions
In
T259771#6687797
@Tgr
wrote:
Anecdotally, I do see people trying to upgrade from 1.16 regularly. (Which of course would still be possible after this change, but more cumbersome...)
They still can, they'd just have to do it in two or three steps. This is pretty standard for upgrading old software.
Probably the most inherently fragile part of upgrades is whether maintenance scripts work with an arbitrarily old schema (hello NameTableStore). But I don't think we'd avoid that problem by restricting to 2-3 LTS releases (ie. 4-6 years).
This is indeed the big issue. And we can't entirely avoid this problem by limiting updates to 2 or 3 LTS releases, but we can greatly reduce it.
Basically, the question is whether we want to continue to commit to testing updates from all previous version, and investigating and fixing any issues that may arrise. In practice, we already don't do that. So we should not pretend we do. We should set clear expectations for release managers, and clear guarantees for users of the release.
Ladsgroup
added a comment.
Dec 14 2020, 11:52 PM
2020-12-14 23:52:25 (UTC+0)
Comment Actions
Agreeing with Daniel. Also, I want to point out:
This policy helps with writing better tests for upgrades, currently we have some tests for sqlite upgrade but it's unclear what is the expectations, what versions it should test upgrading for, etc. as a result, the tests are pretty incomplete.
Upgrading in small jumps is recommended regardless of this RFC, it is a devops principle that deployments should be kept to small as possible. (lean principle? IIRC)
Nikerabbit
added a comment.
Dec 15 2020, 11:59 AM
2020-12-15 11:59:20 (UTC+0)
Comment Actions
Personally, I do upgrades one version at a time, even if updating from LTS to LTS, to minimize the amount of breakage happening at once.
I think it's also good to encourage to upgrade more frequently if they want to do it in one step. On the other hand there is balance to be found to not actually deter upgrades by making them harder. The proposes 2-3 LTS seems sufficient for me.
I think this should also result in an update on one of the policy pages. Maybe
Krinkle
renamed this task from
RFC: Drop support for database upgrade older than two LTS releases
to
RFC: Drop support for older database upgrades
Dec 16 2020, 9:33 PM
2020-12-16 21:33:23 (UTC+0)
daniel
added a comment.
Dec 17 2020, 11:51 AM
2020-12-17 11:51:26 (UTC+0)
Comment Actions
There seems to be consensus that this is a good idea. Two LTS releases as originally proposed seem sufficient, given the fact that old releases can still be updated in multiple "hops".
As discussed in yesterday's TechCom meeting, this seems to be ready for Last Call, but since we already have two RFCs entering Last Call this week, this will have to wait until after January 6th.
daniel
moved this task from
P4: Tune
to
P5: Last Call
on the
TechCom-RFC
board.
Jan 8 2021, 5:56 PM
2021-01-08 17:56:44 (UTC+0)
Comment Actions
Per Wednesday's TechCom meeting, this RFC is entering the Last Call period. If no concerns remain unaddressed by January 20, it will be adopted as policy as proposed:
MediaWiki will support upgrading from at least two LTS releases. For versions for which upgrading is not supported, the installer will fail.
Ladsgroup
mentioned this in
T272199: Drop unsupported upgrade patch files and logic
Jan 16 2021, 2:37 AM
2021-01-16 02:37:13 (UTC+0)
Ladsgroup
added a parent task:
T272199: Drop unsupported upgrade patch files and logic
Leaderboard
added a comment.
Jan 24 2021, 10:18 AM
2021-01-24 10:18:03 (UTC+0)
Comment Actions
But then support for upgrading to intermediate, unsupported, versions must be provided? If I recall correctly, the current guidance is to "ignore" support requests that involve upgrading to an unsupported version. Would a patch be issued if a bug exists in an old version that prevents upgrading to a newer one?
Ladsgroup
added a comment.
Jan 24 2021, 12:09 PM
2021-01-24 12:09:22 (UTC+0)
Comment Actions
I don't think we provide any sort of official support on individual cases (comparing to what canonical provides in exchange for money for example). I don't think we ignore support requests for upgrades of unsupported version. I personally have helped a lot in those cases but at the end of the day it's "help" and not mandatory.
daniel
edited projects, added
TechCom-RFC (TechCom-RFC-Closed)
; removed
TechCom-RFC
Jan 25 2021, 2:56 PM
2021-01-25 14:56:30 (UTC+0)
Comment Actions
This RFC has been accepted with no objections raised during the last call period.
Krinkle
moved this task from
Untriaged
to
Approved
on the
TechCom-RFC (TechCom-RFC-Closed)
board.
Jan 26 2021, 10:09 PM
2021-01-26 22:09:29 (UTC+0)
Tgr
added a comment.
Jan 27 2021, 8:30 AM
2021-01-27 08:30:51 (UTC+0)
Comment Actions
Bit of a stairway thought, but would people doing long-distance upgrades have to set up a server with some intermediary version of PHP for every step (and maybe MySQL although out requirements for that don't change often)? Looking at
Compatibility#PHP
we typically support a given PHP version for two LTS releases.
daniel
added a comment.
Edited
Jan 27 2021, 10:27 AM
2021-01-27 10:27:56 (UTC+0)
Comment Actions
In
T259771#6779292
@Tgr
wrote:
Bit of a stairway thought, but would people doing long-distance upgrades have to set up a server with some intermediary version of PHP for every step (and maybe MySQL although out requirements for that don't change often)? Looking at
Compatibility#PHP
we typically support a given PHP version for two LTS releases.
They might have to upgrade their version of PHP (and possibly MySQL) in multiple steps as well, yes. It's not great, but it's common practice anyway I believe.
Also, everything up to 1.35 can still be done in one step. So someone who, in four years, wants to upgrade from 1.29 to 1.43, will have to do two steps: one to 1.35, and one to 1.43. To upgrade to 1.50 in seven years, you'd go from 1.29 to 1.35 (2020), then to 1.43 (2024), and finally to 1.50 (2027). Not too terrible, I think.
Reedy
mentioned this in
T273080: Stop managing both interwiki.list and interwiki.sql
Jan 27 2021, 4:41 PM
2021-01-27 16:41:51 (UTC+0)
gerritbot
added a comment.
Jan 30 2021, 6:59 PM
2021-01-30 18:59:45 (UTC+0)
Comment Actions
Change 648576
merged
by jenkins-bot:
[mediawiki/core@master] Fail update if bot_passwords doesn't exist
ReleaseTaggerBot
added a project:
MW-1.36-notes (1.36.0-wmf.29; 2021-02-02)
Jan 30 2021, 7:00 PM
2021-01-30 19:00:15 (UTC+0)
Maintenance_bot
removed a project:
Patch-For-Review
Jan 30 2021, 7:10 PM
2021-01-30 19:10:27 (UTC+0)
gerritbot
added a comment.
Feb 5 2021, 1:45 PM
2021-02-05 13:45:14 (UTC+0)
Comment Actions
Change 661913 had a related patch set uploaded (by Ladsgroup; owner: Ladsgroup):
[mediawiki/core@master] Rework sqlite schema changes tests
gerritbot
added a project:
Patch-For-Review
Feb 5 2021, 1:45 PM
2021-02-05 13:45:15 (UTC+0)
gerritbot
added a comment.
Feb 5 2021, 9:52 PM
2021-02-05 21:52:25 (UTC+0)
Comment Actions
Change 661913
merged
by jenkins-bot:
[mediawiki/core@master] Rework sqlite schema changes tests
ReleaseTaggerBot
edited projects, added
MW-1.36-notes (1.36.0-wmf.30; 2021-02-09)
; removed
MW-1.36-notes (1.36.0-wmf.29; 2021-02-02)
Feb 5 2021, 10:00 PM
2021-02-05 22:00:18 (UTC+0)
Maintenance_bot
removed a project:
Patch-For-Review
Feb 5 2021, 10:10 PM
2021-02-05 22:10:33 (UTC+0)
taavi
unsubscribed.
Feb 6 2021, 9:12 AM
2021-02-06 09:12:53 (UTC+0)
Ladsgroup
closed this task as
Resolved
Feb 20 2021, 10:43 AM
2021-02-20 10:43:24 (UTC+0)
Ladsgroup
claimed this task.
Comment Actions
The policy itself is done. The patch to prevent updating from an old version is also merged and we are already dropping lots of old sql files. Calling this done. If you want to follow the progress of clean up, feel free to subscribe to
T272199: Drop unsupported upgrade patch files and logic
Restricted Application
added a project:
User-Ladsgroup
View Herald Transcript
Feb 20 2021, 10:43 AM
2021-02-20 10:43:25 (UTC+0)
Maintenance_bot
moved this task from
Incoming
to
Done
on the
User-Ladsgroup
board.
Feb 20 2021, 11:15 AM
2021-02-20 11:15:20 (UTC+0)
Nemo_bis
awarded a token.
Mar 26 2021, 8:57 PM
2021-03-26 20:57:49 (UTC+0)
Reedy
added a comment.
Apr 6 2021, 9:33 PM
2021-04-06 21:33:03 (UTC+0)
Comment Actions
I just noticed some cleanup/updates needed in RELEASE-NOTES
== Upgrading notes for 1.36 ==
Don't forget to always back up your database before upgrading!

See the file UPGRADE for more detailed upgrade instructions, including important
information when upgrading from versions prior to 1.11.
Ladsgroup
added a comment.
Apr 6 2021, 9:37 PM
2021-04-06 21:37:11 (UTC+0)
Comment Actions
We did it and got reverted:
gerritbot
added a comment.
Apr 6 2021, 11:26 PM
2021-04-06 23:26:01 (UTC+0)
Comment Actions
Change 677378 had a related patch set uploaded (by Jforrester; author: Jforrester):
[mediawiki/core@master] RELEASE-NOTES-1.36: Re-work UPGRADE reference
gerritbot
added a project:
Patch-For-Review
Apr 6 2021, 11:26 PM
2021-04-06 23:26:02 (UTC+0)
gerritbot
added a comment.
Apr 7 2021, 12:53 AM
2021-04-07 00:53:49 (UTC+0)
Comment Actions
Change 677378
merged
by jenkins-bot:
[mediawiki/core@master] RELEASE-NOTES-1.3{6,7}: Re-work UPGRADE reference
ReleaseTaggerBot
added a project:
MW-1.37-notes (1.37.0-wmf.1; 2021-04-13)
Apr 7 2021, 1:00 AM
2021-04-07 01:00:22 (UTC+0)
Maintenance_bot
removed a project:
Patch-For-Review
Apr 7 2021, 1:11 AM
2021-04-07 01:11:07 (UTC+0)
gerritbot
added a comment.
Apr 8 2021, 8:59 PM
2021-04-08 20:59:00 (UTC+0)
Comment Actions
Change 677959 had a related patch set uploaded (by Jforrester; author: Jforrester):
[mediawiki/core@REL1_36] RELEASE-NOTES-1.3{6,7}: Re-work UPGRADE reference
gerritbot
added a project:
Patch-For-Review
Apr 8 2021, 8:59 PM
2021-04-08 20:59:01 (UTC+0)
gerritbot
added a comment.
Apr 9 2021, 12:18 AM
2021-04-09 00:18:44 (UTC+0)
Comment Actions
Change 677959
merged
by jenkins-bot:
[mediawiki/core@REL1_36] RELEASE-NOTES-1.36: Re-work UPGRADE reference
ReleaseTaggerBot
edited projects, added
MW-1.36-notes
; removed
MW-1.36-notes (1.36.0-wmf.30; 2021-02-09)
Apr 9 2021, 1:00 AM
2021-04-09 01:00:35 (UTC+0)
Maintenance_bot
removed a project:
Patch-For-Review
Apr 9 2021, 1:10 AM
2021-04-09 01:10:50 (UTC+0)
Daimona
added a comment.
Apr 13 2021, 11:15 AM
2021-04-13 11:15:56 (UTC+0)
Comment Actions
The task description says:
Affected components: Mediawiki core
Is that still accurate, or are extensions also affected? I think it would make sense to do this for extensions as well, at least those with the "release branches" compatibility policy.
Ladsgroup
added a comment.
Apr 13 2021, 11:22 AM
2021-04-13 11:22:20 (UTC+0)
Comment Actions
It depends on the compataibility policy of the extension I assume. For example, if master of your extension is only compatible with master (most cases). It's safe to drop pre 1.27 as the update.php wouldn't work at all but if it's an edge case (I think language bundle is different, also wikibase) then it depends on the what versions it's compatible with.
Daimona
added a parent task:
T280012: Drop support for old database upgrades from AbuseFilter
Apr 13 2021, 12:02 PM
2021-04-13 12:02:01 (UTC+0)
Lucas_Werkmeister_WMDE
mentioned this in
T247220: Feature Request: data format for portability between wikibase instances
Apr 14 2021, 3:25 PM
2021-04-14 15:25:13 (UTC+0)
Tgr
added a comment.
Sep 25 2021, 2:28 AM
2021-09-25 02:28:24 (UTC+0)
Comment Actions
Is this captured somewhere on-wiki? It would be nice to link it from pages like
Compatibility
Version lifecycle
MediaWiki database policy
Kghbln
added a comment.
Sep 25 2021, 3:03 PM
2021-09-25 15:03:26 (UTC+0)
Comment Actions
In
T259771#7377557
@Tgr
wrote:
Is this captured somewhere on-wiki? It would be nice to link it from pages like
Compatibility
Version lifecycle
MediaWiki database policy
Good point. I do not think so but when doing so
Manual:Upgrading
should also have a link I believe.
Ladsgroup
added a comment.
Oct 6 2021, 6:11 AM
2021-10-06 06:11:33 (UTC+0)
Comment Actions
In
T259771#7377990
@Kghbln
wrote:
In
T259771#7377557
@Tgr
wrote:
Is this captured somewhere on-wiki? It would be nice to link it from pages like
Compatibility
Version lifecycle
MediaWiki database policy
Good point. I do not think so but when doing so
Manual:Upgrading
should also have a link I believe.
It does have documentation about it:
Kghbln
added a comment.
Oct 6 2021, 8:01 AM
2021-10-06 08:01:50 (UTC+0)
Comment Actions
It does have documentation about it:
Good. Did not see this in the heat of the action. :) Thanks. The spots Tgr mentioned do also make sense to me tough. Thus I now added the note to these pages, too. From your reply I am not sure how you think about it. Please revert or tweak at your linking.
Ladsgroup
added a comment.
Oct 6 2021, 8:42 AM
2021-10-06 08:42:37 (UTC+0)
Comment Actions
Added to all three.
Mainframe98
mentioned this in
T303684: Remove unused configuration global $wgLegacySchemaConversion
Mar 13 2022, 1:45 PM
2022-03-13 13:45:32 (UTC+0)
Bawolff
added a comment.
Apr 1 2022, 6:21 AM
2022-04-01 06:21:58 (UTC+0)
Comment Actions
Just as an aside, i feel like i've seen an increase in support desk questions because of this. In particular people will try to to do the upgrade in steps, but then they will try and use an old version of mw with php8 and have problems.
Reedy
mentioned this in
T313164: 1.38 installer talks about extensions migrated into core in MediaWiki version 1.14
Jul 16 2022, 4:58 PM
2022-07-16 16:58:21 (UTC+0)
Tgr
mentioned this in
T314909: Running update.php with an empty database should reinstall the tables, throws "Can not upgrade from versions older than 1.31" instead
Aug 10 2022, 1:43 AM
2022-08-10 01:43:24 (UTC+0)
Emufarmers
subscribed.
Oct 16 2022, 4:56 PM
2022-10-16 16:56:25 (UTC+0)
Comment Actions
The error message
Can not upgrade from versions older than 1.29, please upgrade to that version or later first.
is confusing. I
am
upgrading to 1.29 or later!
In
T259771#6779692
@daniel
wrote:
Also, everything up to 1.35 can still be done in one step.
Based on (a misreading of) this, for an upgrade from 1.18, I went with 1.34 as the intermediate version and it worked fine. Could the error recommend specific versions to upgrade to?
mentions 1.2
and 1.35.
In
T259771#7823888
@Bawolff
wrote:
Just as an aside, i feel like i've seen an increase in support desk questions because of this. In particular people will try to to do the upgrade in steps, but then they will try and use an old version of mw with php8 and have problems.
Which versions are they using? PHP8 worked fine for me with 1.34, but I don't know how far back you can go before it breaks, and new breakages will probably emerge over time as things change in PHP. Probably a good reason for us to recommend the newest old version that we can.
Ladsgroup
added a comment.
Oct 18 2022, 2:15 PM
2022-10-18 14:15:57 (UTC+0)
Comment Actions
In
T259771#8319359
@Emufarmers
wrote:
The error message
Can not upgrade from versions older than 1.29, please upgrade to that version or later first.
is confusing. I
am
upgrading to 1.29 or later!
That is fair. What do you think it should be? Patches are welcome :)
Krinkle
mentioned this in
T325706: Work out what to do with ConcatenatedGzipHistoryBlob in our future
Dec 21 2022, 5:01 PM
2022-12-21 17:01:29 (UTC+0)
Ladsgroup
mentioned this in
T166010: The Great Namespaceization Effort
Dec 23 2022, 8:03 AM
2022-12-23 08:03:58 (UTC+0)
Tgr
mentioned this in
T326071: Upgrade from 1.31.2 to 1.39 results in pages no longer being usable with "The revision #0 of the page named "x" does not exist." error
Jan 3 2023, 1:41 AM
2023-01-03 01:41:54 (UTC+0)
Bugreporter2
awarded a token.
Nov 13 2023, 3:18 AM
2023-11-13 03:18:29 (UTC+0)
ValerioBoz-WMCH
mentioned this in
T278033: Upgrade testing-Wikimini from MediaWiki 1.28.0 to 1.39
Mar 4 2024, 7:18 AM
2024-03-04 07:18:18 (UTC+0)
Dreamy_Jazz
mentioned this in
T360421: Remove 1.34 and before schema updates from GlobalBlocking
Mar 19 2024, 11:41 AM
2024-03-19 11:41:47 (UTC+0)
Ladsgroup
mentioned this in
T331608: Update error 1.39.1->1.39.2: "Can't DROP 'user_timestamp'; check that column/key exists"
Mar 27 2024, 5:12 PM
2024-03-27 17:12:28 (UTC+0)
Krinkle
moved this task from
Approved
to
Implemented
on the
TechCom-RFC (TechCom-RFC-Closed)
board.
Aug 7 2024, 4:07 PM
2024-08-07 16:07:48 (UTC+0)
Xqt
mentioned this in
T378984: Drop support for MediaWiki <= 1.30
Nov 4 2024, 3:06 PM
2024-11-04 15:06:59 (UTC+0)
Log In to Comment
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct.
Wikimedia Foundation
Code of Conduct
Disclaimer
CC-BY-SA
GPL
Credits