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
Show replies by date