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
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
<amir.aharoni(a)mail.huji.ac.il> 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 <agarrett(a)wikimedia.org>rg>:
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
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l