Hey folks,
I'd to modestly propose that we talk about managing/announcing breaking changes to core MediaWiki architecture.
I want to have this chat because I spent an hour or two yesterday trying to figure out why changing default configuration options for an extension in MyExtension.php wasn't working. Apparently, now, you also have to change it in extension.json for it to work on Vagrant.
I understand that this was a change that was announced on wikitech-l, but I don't think that I'm the only one who thinks that reading wikitech-l isn't a good use of time, compared to, say, doing my job (irony upon ironies, I know). If you want to change the way that things have worked for 11 years, then making engineers understand what they need to do differently is your responsibility, not mine.
So, besides huffing and puffing, I have two small proposals:
1. We should have a low-volume list/RSS feed/twitter account/something where we announce major breaking changes like this, that doesn't involve reading 20 emails per day of other stuff that doesn't affect the way I do my job.
2. If we make breaking changes, the change should be really obvious so that I can't spend hours trying to find out what changed.
For example, when we did the i18n JSON migration (everybody seems to love JSON these days), and I went to change/add a message, I found that the message file was a completely different format, and I was clued in straight away to the fact that something was different.
By contrast, in this case, the way I'd done things for years suddenly stopped working. I've heard it justified in this particular case that this is just a transition period; but it's not just a transition period for code, it's a transition period for practices, and therefore it's the time when it should be the LEAST confusing for engineers who don't care about your refactoring, not the MOST confusing.
— Andrew Garrett