The last release is still buggy, as proven here:
https://travis-ci.org/doctrine/dbal/builds/155125956
and as confirmed here:
https://github.com/sebastianbergmann/phpunit-mock-objects/pull/324

Some packages are using symfony/console 3.0 and newer as requirement, and doctrine/dbal works well with this contstrain.

It has a bug that makes it incompatible with the doctrine dbal test
suite, see
https://github.com/sebastianbergmann/phpunit-mock-objects/issues/322
Fixes #2475

The bin/doctrine-dbal.php file is not an executable file. Adding them as a bin in composer.json means that any composer install will trigger changes in the source when using symlinks because of the chmod. This makes things a pain when installing from source.
Thus, there is no valid reason to add it. It is absolutely not necessary when using a composer install. The issue requesting it previously is actually an issue in Laravel which replaces the proxy file/symlink generated by Composer with a copy of the original file, which of course cannot work because of paths used in require. But copying a second file does not help for that (unless in very specific cases). It only moves the issue until the next require call.

Adding doctrine-dbal to composer.json and making it work just like doctrine command (from Doctrine ORM)

- Switch from phing to ant
- Add composer archive for packages
- Remove PEAR package building

By having more specific autoload prefixes it is possible to reduce the number of stat calls made.