Upgrade PHPUnit to latest 4.8.x

This is the relevant change in composer.json.

diff --git a/core/composer.json b/core/composer.json
index abb57e6..ef9b510 100644
--- a/core/composer.json
+++ b/core/composer.json
@@ -34,7 +34,7 @@
     "behat/mink": "~1.6",
     "behat/mink-goutte-driver": "dev-master#cc5ce119b5a8e06662f634b35967aff0b0c7dfdd",
     "mikey179/vfsStream": "~1.2",
-    "phpunit/phpunit": "4.8.*",
+    "phpunit/phpunit": "~4.6",
     "symfony/css-selector": "2.7.*"
   },
   "replace": {

I should point out again that even though composer.json now requires a minimum of PHPUnit 4.6, the patch actually contains the latest stable, which is 4.8.7.

I believe we are marking all external library upgrades as critical before RC. If this is not the case, please downgrade.

@dawehner: I believe that we should still decrease the minimum required version to the version we actually need. We had changed it to 4.8.* in #2400407-68: [meta] Ensure vendor (PHP) libraries are on latest stable release just to upgrade but it was not necessary then.

@dawehner: The update to PHPUnit was committed recently in #2400407-68: [meta] Ensure vendor (PHP) libraries are on latest stable release, and the version constraint was changed just to update. I don't think we have added anything to tests since then (it's only 10 days or so). We can test in a patch to see. I will do that now.

@chx: We are not dropping 4.6. I don't think we are using anything new after 4.6 in any of our tests as we upgraded only about 10 days back. I will test to be sure though. I believe we could still use PHPUnit 4.6 and our composer dependencies should point to that. That would be relevant if we use Drupal in a composer workflow.

Mixologic outlined why we should do this in #2400407-53: [meta] Ensure vendor (PHP) libraries are on latest stable release.

I am just testing the attached patch with PHPUnit 4.6.10. If it fails, then we could just play it safe and change the version constraint to ~4.8.

I'll try to explain this a bit more clearly.

We have tried and kept up to date with all our external libraries over the past few months. It is a good idea to upgrade even if we are not using the new features so that we can be sure that we are on the latest stable branch. As long as there are no BC breaks, it is very simple to keep up to date as well.

However, while updating, we also increase the version in composer.json even if we didn't need to. PHPUnit is one example where this happened; composer/installers is another example (see #139).

Normally, this doesn't matter as we ship with composer.lock, but if used Drupal with a composer based workflow, Drupal's composer.lock would not be used and we may get any version. Also, think of another scenario: Another component needs PHPUnit 4.9, but since we have locked it to PHPUnit 4.8.*, that package won't be able to work with Drupal, even though it should.

To keep things simple, our composer version constraints should just specify the range of versions we can work with rather than locking to just the latest version. This ensures maximum compatibility possible.

I am just waiting on the patch in #10. If it turns green, then we are not using any new features introduced after PHPUnit 4.6.10. If it fails, then we are using newer features and we should modify the composer.json to ~4.8.

FWIW, I am not even sure if 4.6 is required. It could just be that the same thing happened earlier and it got increase in an update, but I don't know when that might have happened and hence using 4.6 as base now (as it is just 10 days old).

Thanks @dawehner. That is certainly an interesting thought.

On thinking more about it, it seems to me that it comes down to using the tool properly. Consider two scenarios:

1. The people who wouldn't know enough about composer to require the necessary version in their setup would not be using the composer workflow in the first place. In that case, they would get what we ship with Drupal core as per the composer.lock file, i.e., the version we specify.
2. The people who use the composer workflow would/should know enough to specify the version they need.

In both the scenarios above, the problem is averted.

The patch in #10 is green. This means that we don't really need anything more than 4.6, but we should stick to the latest version, of course. I think the patch in #1 is still valid. We should discuss a bit on #12 and #13 before proceeding. I don't think this is very urgent, considering it is only a patch upgrade.

I am not married to either approach but I think the version constraint ~4.6 makes sense as it allows a wider range of components to work with Drupal. If there are significant disadvantages to using that, then we could switch to ~4.8.

There has been no response here. Also, PHPUnit 5 came out and I am not sure if PHPUnit 4.6 is supported anymore. The website lists 4.8 as supported. The composer.json in this patch now specifies a constraint of ~4.8.

I am still keen to revisit this but I think we have waited long enough. Let's update to 4.8.10. :)

Okay, I messed up with that patch in #20. It modified the wrong composer.json file. I am working on a new patch now.

Here is the proper patch.

@dawehner: I am not entirely sure. I think that was a composer version mismatch. I upgraded and recreated the patch again. The line had already disappeared due to another issue that got in. Uploading a new patch.