Just to add to Daniel's statement, and as I said previously, the reality of the
upgrade process, and the problems most have with it, is summed up in the statistics. As I
recall, I think, over 70% of all wikis monitored are using an old, outdated version of
Mediawiki. Additionally, as I recall, the user survey found the upgrade process is one of
the top concerns of third party users. And consider a survey is generally only answered by
people who feel vested into the subject. I think almost all third party users would gladly
give a big thanks to everyone involved in the development of the software, but they also
are speaking very loudly (counting the 70% who don't upgrade) with their words, &
actions, that the upgrade process needs to be easier.
Sent from my iPad
On Dec 15, 2015, at 7:34 PM, Daniel Bishop
<aerosatar(a)gmail.com> wrote:
I usually don't weigh in on these conversations, but I feel like I should speak up
here too. I must also mention that, while I am not a developer, I *am* a reasonably
technically capable user.
All that being said: Mediawiki is hard to upgrade. That is a fact. It is the *only*
software I have ever come across where the Official upgrade instructions are, essentially,
"make a backup and do a completely fresh install, run a script, then
re-customise".
And before anyone says that isn't true, these are taken from the Mediawiki upgrade
page:
"You should put the decompressed tarball in a new and empty folder on your server.
If you instead extract the new version directly on top of your old version, rather than in
a new directory, you should follow the instructions described in Back up existing files
and the database: otherwise, if you've made any customizations you may erase them in a
way that leaves you with no reference to re-apply them from. Extracting a tarball over top
of your live copy of MediaWiki can also leave behind files from the old version of
MediaWiki which may interfere with the upgraded code. It's recommended that you unpack
the new files into a new directory, and then apply customizations to the new directory
(restoring LocalSettings.php, images folder, extensions, and other customizations like
custom skins)."
"If using Git, export the files into a clean location, and then copy the old
customized files into the new location as described in the previous section."
Simply dismissing people's completely valid comments about this with "your case
is not normal" (and similar) is not conducive to the continued life of your product.
(Yes, Mediawiki is essentially open-source freeware, but it is still a product.)
There are a lot of software packages out there that update more frequently than Mediawiki
does (in terms of official releases), but all of these have few- or no-click updates. Why
does Mediawiki require a completely fresh install every time? Why can a new installation
and update method not be developed?
Jan, and many others, have made a lot of valid comments on this discussion. So why have
they all been summarily dismissed with such... complete lack of consideration?
We are not all developers. We do not all have that level of skill.
We are not all able to devote large amounts of time to keeping the software
'up-to-date' with the current (rather involved) method.
We are not asking for the more edge-case scenarios to all be covered in every way
possible (a gap of several years *should* require/be best served by a fresh install).
We are simply asking for it to be easier to upgrade our Mediawiki installations so that
we can make use of the features, improvements and fixes that the developers put time into
doing. (Which, incidentally, would also likely vastly reduce the number of edge-case
installations out there.)
The fact that this whole debate was started over a question about PHP versions (i.e.
software dependencies) is also rather interesting.
Regards,
AerosAtar
P.S. FWIW, my install is 1.26a (559e61e) running on PHP5.6.4-4ubuntu6.3 (fpm-fcgi).
P.P.S. Apologies if my thoughts are not entirely coherent or do not make complete
sense... I usually stay out of such conversations for a reason. ;)
-----Original Message-----
From: MediaWiki-l [mailto:mediawiki-l-bounces@lists.wikimedia.org] On Behalf Of Jan
Steinman
Sent: 15 December 2015 21:33
To: mediawiki-l(a)lists.wikimedia.org
Subject: Re: [MediaWiki-l] MediaWiki-l Digest, Vol 147, Issue 3
From: Tim Starling
<tstarling(a)wikimedia.org>
All good points, and yet:
Your case is not normal. That
is the price you pay for upgrading MediaWiki as often as other people
paint their houses.
That's a useful analogy. One doesn't hire a staff painter to be on-hand, touching
up little nicks here and there as they develop over time unless painting is but a small
part of the operation. For most people, one waits until it actually needs painting.
I have farm plants and animals to take care of, and a not-for-profit organization to run,
and I volunteer for numerous other organizations. I don't have time to baby-sit a
computer.
This is not an easy thing to hear nor understand for those who spend all their time
baby-sitting computers for a living. I know -- that was me in another life!
So, one *could* say, "Hey, if we made upgrading as easy as paint drying, more people
would keep up!"
Or one can self-righteously blame the victim for having a life beyond keeping up with
every little upgrade.
(Postscript: I composed that message a week and a day ago. Then I felt guilty, and
proceeded to go on an "upgrade binge," bringing my OS up from 10.6.8 to 10.10.5,
which would have given me -- among other things -- PHP 5.6. End result: my email and
website were down for a week as I struggled to get my server's environment back, and I
never did get a working upgrade installed. This is coming to you from a restored backup. I
feel vindicated.)
Jan Steinman
EcoReality Co-op,
http://www.EcoReality.org
2152 Fulford-Ganges Road
Salt Spring Island, BC V8K 1Z7 CANADA
+1 250.653.2024
_______________________________________________
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
_______________________________________________
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l