Topic on Talk:Stable interface policy

Since 1.39, the installer will warn about the use of deprecated settings. But this only works as long as the declaration of the config setting is kept. Since people often upgrade from old versions after many years, it seems useful to keep the declaration around for a long time.

The old setting can however be ignored. The deprecation warning can just say that the setting no longer works. We just need to declaration in place so the installer tells the user.

Maybe instead of using the "deprecated" flag in the schema, we should have an "obsolete" flag for settings that are no longer supported? We could keep them indefinitly.

This is a great idea, though it seems like we could do both? Warn on deprecation and for obsolete settings?

Yes, of course, it should do both! But deprecated settings would still work, while obsolete settings would be defunct. The idea here is to make the distinction explicit, and allow backwards compatibility code for old settings to be removed without breaking old installs without explanation. Being able to declare settings as obsolete will allow us to break old installs WITH explanation ;)

(I just realized I have been editing here with two accounts - full disclosure: User:Duesentrieb is also me, that's my private account)

I made a patch that introduces the an "obsolete" marker into MainConfigSchema, and uses it in the updater and structure tests: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/838769

@DKinzler (WMF), I agree with you on the "obsolete" flag. It will inform 3rd party users to cleanup their LocalSettings.php and remove what is no longer needed for their installs (or update to the new ways of doing things).

Since we can't know what outside user LocalSettings.php looks like, this a good strategy to keep things clean on their own side too, which after sometime, cleaning up these configs from core would be safer.

But the thing is, how long do we want to keep the deprecated configs? 2, 5 or 10 years before completely removing?

With this mechanism in place, we could start to remove backwards compat code for deprecated settings more agressively, after or two releases, like other deprecated code. The declaration of the obsolete setting would need to be kept for as long as we support upgrading from a revision where the setting was not deprecated (but not before two LTS releases from now, because older versions don't emit warnings).

I.e. if in 1.44 we drop support for upgrading from 1.35, we can remove all obsolete config that has been deprecated since at least 1.35. This would be safe since when upgrading to 1.44 from a version > 1.35, you'd see the warnings. And when upgrading from an older version, you'd have to upgrade to a version < 1.44 first, so you'd also see the warnings.

Since we currently guarantee updates across two LTS releases, and we do an LTS release every other year, this would come to four to five years from deprecation to full removal. The b/c code could already be removed after about a year, though, moving the seeting from deprecated to obsolete.

Something that more interactively helps sysadmins when upgrading to know what config they need to update/remove would be really great, rather than hoping that people carefully read the upgrade notes. Great plan.

@Jdforrester (WMF), you captured it very well and I like how you put it. In this case, we're guiding the customer/end-users on how to configure their wikis and what to remove which is no longer needed for/after upgrades.

I think a lot of sysadmins will be happy to see this feature (as here we're putting MW users again on the front line) and it'll make their life a whole lot easier when managing those giant LocalSettings.php files :)