I don't think we need to announce every change that requires running update.php-- that's pretty common, and (most importantly, imho) the error messages you get when that happens make it pretty obvious what you need to do.
But +1 for standardizing where breaking changes are announced. I hit the issue yesterday with profiling. It's been updated, the change wasn't announced on wikitech-l, and the wiki page about it is wrong. So I'd also like to also suggest that if you make a breaking change: * please make sure mediawiki.org is updated to reflect the change * please fail in a way that tells the user what went wrong I know I'm guilty of making breaking changes that don't comply with this, so I'm preaching to myself too. But I think that would generally help. On Thu, Feb 12, 2015 at 6:18 AM, Amir E. Aharoni <[email protected]> wrote: > I do have a lot of respect towards the people who work on modularization > and librarizatin and vagrant and all that, but yes - I generally agree. > There's the API mailing list, and many emails on it are about breaking > changes, but it has relatively low traffic in general, so it's OK to mix > it. Wikitech-L has very high traffic, and as Andrew says, such > announcements can get lost, if they are sent at all. So a separate > MediaWiki-breaking-changes-L list sounds quite reasonable to me. > > And I offer some simple yardsticks for defining a "breaking change": > * It's definitely a breaking change if your local site stops working after > running `git pull`. > * It's definitely a breaking change if it's in core or in an extension used > by Wikimedia, and it requires running any of the following: > ** update.php > ** composer update (not every minor new version of an external library, but > a MediaWiki feature that depends on that new version) > * It's definitely a breaking change if it's in core or in an extension used > by Wikimedia, and it requires changing Git configuration. > > Other suggestions are welcme. > > A recent example of such change is the series of changes in the way that > skins' source is managed. It broke my installation several times and I had > to figure out how to change LocalSettings myself time after time. The > result was pretty awesome, because modularization is usually a good thing, > but I don't remember that the changes were announced in a way that was > convenient, at least to me. > > > -- > Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי > http://aharoni.wordpress.com > “We're living in pieces, > I want to live in peace.” – T. Moore > > 2015-02-12 15:40 GMT+02:00 Andrew Garrett <[email protected]>: > >> 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 >> _______________________________________________ >> Wikitech-l mailing list >> [email protected] >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
