Greetings, colleagues. I took the PHP survey, so that part is done, but I'd like to weigh in on some of the comments I've seen in this thread. I have read all of your comments, and I agree with everything written here.
First and foremost, thanks to all who support the software and the community. This mailing list gives me a welcome word every day. I believe that using the latest software is almost always a good idea. We are going to upgrade eventually - why deny ourselves the benefits of the latest software by putting off the upgrades? The only argument in favor of delay would be a breaking change, and this is something that the authors of the software must publicize. Second, I'm very empathetic to anyone who experiences troubles installing products or doing upgrades. In the PHP world, we have worked hard to make the major systems (WordPress, Joomla, Drupal, Laravel, etc.,) easy to install and upgrade, and to clearly identify breaking changes from one version to the next. It's almost axiomatic that breaking changes may not occur from one release to the next. The PHP-FIG (Framework Interoperability Group) has been instrumental in guiding our thinking on this point. PHP version 5, since PHP 5.3 has been pretty stable. I have not experienced a breaking change at all, up through PHP 5.6+. I have experienced deprecation warnings (mostly related to the antiquated MySQL extension) but these warnings can be suppressed, allowing time for developers to change to a supported database extension. This model of "deprecation before abandonment" has proved very useful for those of us who want to be up-to-date, and has given ample notice to those of us who want to remain on old software. PHP version 7 (there is no version 6) introduces breaking changes with the removal of previously deprecated features. But it's also much faster and has better language support for some modern design and coding techniques. That said, it seems logical to me that future releases of MW should "just work" with PHP 7. There may be a good bit of work between "should" and "just works" but this seems like an enticing objective. Some MW Extensions use PHP code that is PHP release-dependent. Finding and catching these instances before installing a breaking change is not easy. For example, consider a PHP 5.3 platform that needs the EmbedVideo extension. There is a gotcha - EmbedVideo uses a PHP array notation that is not supported in PHP 5.3. This is something that Composer is supposed to help us with. Throughout the PHP community, the universal advice is "If you're not using Composer yet, start using Composer!" Though I resisted that advice for a couple of years, I've found Composer to be one of those things like Git version control. It can save you much more than it costs you. So I would encourage anyone reading this thread to consider Composer and embrace it if possible. Perhaps greater publicity about Composer should issue forth from the Foundation? Perhaps there should be a community-standards requirement to use Composer to publish new or updated versions of MS Extensions? And on a slight tangent, but related... A native and naked installation of MediaWiki should not be an inviting hacker target. We should be able to download and install the software without having to think too much. Then we should be able to extend update rights to our community according to our community's needs. "Built by devs for devs" is so 2005. Less configuration and more convention is a better paradigm for our future. Again, thanks to all. I hope to see you in San Francisco, Ray Paseur Armedia, LLC _______________________________________________ MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
