How to handle multiple php versions requirements?

[ralt]

Say, I have 2 versions of my library, one on php 5, the other on php 7 (using STH, for example). Both versions have the same features and bug fixes.

How can I handle this with composer? Can I do this with branches somehow? Will tags work correctly? For example, should I have 1.0.0-5 and 1.0.0-7? Do I need different major versions? Upping the major number would mean upping by 2...

[trowski]

I tweeted something similar @Seldaek about the same time you posted this. 1.0.0-5 and 1.0.0-7 would be treated as unstable versions.

So far the only solution I've come up with is having different major versions targeting different PHP versions, but then users cannot rely on Composer auto-detecting the correct version to install on PHP 5 since it will complain that your version of PHP does not meet the package requirements.

[alcohol]

Are they different in source? As in, does the php 7 variant not run on php 5? In that case it clearly is a new release that is not backwards compatible, so it would make sense to up the major version number.

[nevvermind]

If you consider your library version which uses PHP7 as a "preview" one, and the PHP5 the mainline (master), you could use two branches for your releases.

The PHP5 will contain stable releases (tags) and the PHP7 alpha/preview/beta branch will have tags like 2.0.0-alpha1 (or whatever major version you'd use). You'll then be maintaining two versions of your lib, porting or backporting stuff from one to another, until you decide that the PHP5 one goes EOL.

But what @alcohol said still stands: if the PHP7 version won't work in PHP5, that's a BC break, so a new major version is justified.

[Seldaek]

Following semver.org yeah I would say you need a 1.0 branch to maintain PHP5 compat for a while and then bump master to be 2.0 and move on from there.

[trowski]

Originally @ralt and I were discussing a PHP 7 version that had the same API. The code in the PHP 7 branch would not be PHP 5 compatible, but a user could upgrade to the PHP 7 version without changing any of the code using the library. Still, a major version bump for the PHP 7 branch makes the most sense.

Composer already will install previous minor versions if the current version is not compatible with the installed version of PHP. Would it be possible and sensible to have Composer move back to a previous major version as well? That is, if a user ran composer require vendor/package and 2.x required PHP 7, could Composer automatically try installing 1.x?

[nevvermind]

if a user ran composer require vendor/package and 2.x required PHP 7, could Composer automatically try installing 1.x?

Isn't that what Composer would do anyway provided a laxed constraint, like >=1.0 <3.0?

[trowski]

I was referring to a user installing a package for the first time by typing composer require vendor/package without a version number. Dependent packages would use a laxed version constraint. I experimented with this yesterday with a v2.0 branch requiring PHP 7 and a v1.0 branch requiring only PHP 5.5+. Running the command as above resulted in Composer stating that a compatible package could not be found, even though the v1.0 branch was compatible.

Just trying to make it as easy for users as possible. Of course the docs would make it clear that PHP 5 is supported by the older version, but sometimes users overlook such information.

[nevvermind]

Throwing this out there: what happens when you use composer update --prefer-lowest?

[trowski]

what happens when you use composer update --prefer-lowest?

Then the lowest compatible versions of all packages are installed, not exactly ideal and it doesn't really address the problem at hand: initial installation of a package.

[alcohol]

Can you show us the composer.json of the respective versions/branches? Are they on github by any chance?

[trowski]

I quickly put together an example on GitHub of the schema I'm talking about at https://github.com/trowski/composer-test and added this repo to Packagist as trowski/composer-test. The master branch is tagged as v2.0.0 with composer.json requiring PHP >=7.0.0-dev. The v1.x branch is tagged as v1.0.0 and requires PHP >=5.5.

When I run composer require trowski/composer-test on a machine with PHP 5.5 installed, I get the following:

Using version ^2.0 for trowski/composer-test
./composer.json has been created
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Installation request for trowski/composer-test ^2.0 -> satisfiable by trowski/composer-test[v2.0.0].
    - trowski/composer-test v2.0.0 requires php >=7.0.0-dev -> your PHP version (5.5.24) does not satisfy that requirement.


Installation failed, deleting ./composer.json.

Changing the command to composer require trowski/composer-test ^1 solves the problem, but requires the user to know that a prior version exists that supports PHP 5.5.

[alcohol]

Well, ok I understand your issue.

But in my humble opinion, it makes sense that composer does not really know what to do at this point. It shouldn't just pick a lower version simply because your current system is running php version X. When being ambiguous like this, it makes more sense for composer to just fail because it cannot match the highest available version to your environment. If you know that there is a lower available version that specifically matches your current environment and suits your needs as a package, then you should be explicit in your version requirement. Leaving it wide open means you let composer determine the best version, which will (almost) always be the highest stable version.

If composer were to magically resolve it according to your expectations, then that would mean inconsistent behavior, since the same command would result in different versions depending on the environment. That is not desirable behavior.

[trowski]

Composer will already install different versions depending on environment if it's only a minor version difference. If I were to tag the versions in the example repo with the same major version, such as v1.1.0 for the PHP 7 branch and v1.0.0 for the PHP 5.5+ branch, then Composer automatically installs v1.1.0 with PHP 7 and v1.0.0 with PHP 5.5. Maybe this is a bug and not desired behavior?

I was just looking for an elegant solution to maintaining branches targeting different versions of PHP while keeping it simple for users. The solution appears to be tagging the branches with different major versions and just making it very clear in the installation instructions which versions to use depending on the installed version of PHP. Thanks for your help and input!

[Seldaek]

On 01/06/2015 18:31, Aaron Piotrowski wrote:

Composer will already install different versions depending on
environment if it's only a minor version difference.

As far as I know this is not the case.

Besides, either way will require you to maintain two branches for PHP5
and PHP7 IMO. The major version way just means you respect semver more,
which I think is a good thing.

I would not worry about it too much. It'll be a community-wide "pain"
and not just for your project as more and more projects migrate to PHP7,
so I think users will quickly have to educate themselves and understand
that this error message probably means they need to require an older
version if they aren't using 7 yet.

[trowski]

As far as I know this is not the case

I stand corrected. I should have tested it again before making that post. I must have made a mistake the first time I tested that scenario that allowed the lower version to be installed.

It'll be a community-wide "pain" and not just for your project as more and more projects migrate to PHP7

You're certainly correct, so I should have little reason to worry as most projects will face the same problem. Thanks again!

[ghost]

I have 4 PHP (5.3, 5.4, 5.5, 5.6) versions on my DEV server (Windows 2012, IIS, PHP Manager)
When I need Composer to install a project which have a specific PHP version behind, I change my Windows system variable for the PATH and the PHPRC variables to that PHP version then reboot the server !.... and Composer install works fine for that requested project ! Maybe this is a hint to solve your problem...