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 <[email protected]> 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:[email protected]] On Behalf > Of Jan Steinman > Sent: 15 December 2015 21:33 > To: [email protected] > Subject: Re: [MediaWiki-l] MediaWiki-l Digest, Vol 147, Issue 3 > >> From: Tim Starling <[email protected]> > > 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 _______________________________________________ MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
