version 1.1.0 broke phpunit on PHP 5.4 ~ PHP 5.6 about instantiator HOT 7 CLOSED

I am stunned at the level of arrogance from the doctrine team that considers removing a PHP major version not to be a BC break. But lesson learned. In future we should all pin to a feature version instead of allowing our systems to benefit from new features by pinning on the major version. Quite staggering.

However, for others that can't get to grips with the disappearance of PHP 5.X support in doctrine/instantiator V1.1.0, a simple fix is to put

"doctrine/instantiator": "1.0.5"

in your require-dev section. Phpunit, V 4* which uses it, will happily start working again.

from instantiator.

Hi,
following tests on my side, and instead of setup a static "doctrine/instantiator" version's. I finally setup a target platform php version by adding a config::platform section to the composer.json, cf. example under (doc).

    "config": {
        "platform": {
            "php": "5.6.32"
        }
    },

After composer update, doctrine/instantiator version (in composer.lock) is resolved to:

            "name": "doctrine/instantiator",
            "version": "1.0.5",

my 2 cents.

from instantiator.

I had that problem too. Here's what happened to. On a fresh Macbook Pro, High Sierra comes with php7, I configure Laravel and updated composer with php7. And then I switched to php5.6.31, which was incompatible with installed version of doctrine/instantiator.
I re run composer update and then it downgraded the doctrine dependencies and it works:

`- Updating mtdowling/cron-expression (v1.2.0 => v1.2.1): Loading from cache

• Updating symfony/polyfill-util (v1.5.0 => v1.6.0): Downloading (100%)
• Updating symfony/polyfill-php56 (v1.5.0 => v1.6.0): Downloading (100%)
• Updating doctrine/inflector (v1.2.0 => v1.1.0): Downloading (100%)
• Updating artesaos/seotools (dev-master => 0.10.0): Downloading (100%)
• Updating doctrine/collections (v1.5.0 => v1.4.0): Downloading (100%)
• Updating doctrine/cache (v1.7.1 => v1.6.2): Downloading (100%)
• Updating doctrine/annotations (v1.5.0 => v1.4.0): Downloading (100%)
• Updating doctrine/common (v2.8.1 => v2.7.3): Downloading (100%)
• Updating doctrine/dbal (v2.6.2 => v2.5.13): Downloading (100%)
• Updating jaybizzle/crawler-detect (v1.2.52 => v1.2.54): Downloading (100%)
• Updating pragmarx/support (v0.8.3 => v0.8.5): Downloading (100%)
• Updating doctrine/instantiator (1.1.0 => 1.0.5): Downloading (100%)
• Updating maxmind-db/reader (v1.1.3 => v1.2.0): Downloading (100%)
• Updating phpdocumentor/type-resolver (0.4.0 => 0.3.0): Downloading (100%)
• Updating phpdocumentor/reflection-docblock (4.1.1 => 3.2.2): Downloading (100%)`

from instantiator.

See http://doctrine-project.org/2017/07/25/php-7.1-requirement-and-composer.html. Run composer update on PHP 5.x and you'll get a compatible version. Closing as invalid.

from instantiator.

While that works, it's a bit ugly to have to do an update immediately after an install.

from instantiator.

If your install is broken, then that's just because the locked dependency set is not compatible with your PHP version, and they shouldn't be locked to that set in first place

from instantiator.

You can put ^1.0.0 and let the SAT deal with it. There is nothing breaking here, except what was already widely explained above and in the linked article.

If you run composer update and composer install on incompatible systems, or if you prepare deployment packages on a system that is incompatible with your production environment, you will get into trouble anyway.

from instantiator.