PHPUnit 3.7 removed from composer.json because of incompatibilities

[SenseException]

dbunit 1.3.2 is the first version introducing PHPUnit 4.* while still supporting PHPUnit 3.7.*. The current composer.json file of dbunit allows both versions.

Before PHPUnit 4, the class PHPUnit_Framework_Constraint had no constructor, which changed in 4.0:

    public function __construct()
    {
        $this->exporter = new Exporter;
    }

With dbunit 1.3.2 using PHPUnit 4.*, the dbunit constraint classes are calling this parent constructor parent::__construct(), which does not exist in PHPUnit 3.7. This results in a fatal error.

I'm not sure how this should be handled and I haven't checked if there are more breaks like this one, so I've created the simplest but radical solution by removing PHPUnit 3.7 support from dbunit 1.3.2. Doing this in a minor release isn't a usual solution, so I'm all ears about compatibility to 3.7.

An alternative solution would be giving dbunit a dependency to sebastianbergmann/exporter and removing the parent call to the PHPUnit_Framework_Constraint::__construct(), overwriting the constructor and the $exporter property and setting the Exporter in dbunit too.

But who knows what kind of changes PHPUnit gets in the future which forces dbunit to further adaptations for its constraints and it is not hard to downgrade to dbunit 1.3.1 for a PHPUnit 3.7 user. So I decided for myself to make this PR a change of composer.json.

[elazar]

@sebastianbergmann Would you say it's worth maintaining PHPUnit 3.7 compatibility in DbUnit? I could see modifying the DbUnit constraint constructors to have a conditional check using version_compare() against PHPUnit_Runner_Version::id() such that the parent constructor that doesn't exist in PHPUnit 3.7 isn't called.

[sebastianbergmann]

I am not spending time on PHPUnit 3.7 anymore.

[elazar]

Merging, then. I'll try to see about tagging a release soon. Thanks @SenseException.

[SenseException]

Thank you too.