Test lowest version constraints

[andig]

Follow-up of #101 and #111.

See https://travis-ci.org/andig/http/builds/200662157 for sample output. It already shows that ringcentral:1.0 is broken. https://travis-ci.org/andig/http/jobs/200662167 shows some additional errors that should be investigated once ringcentral/psr7 is upgraded to 1.2.

Note: this doubles the build matrix

[WyriHaximus]

Doubling is a wee bit much tbh. This adds only one build:

env:
  - DEPENDENCIES=default

matrix:
  include:
    - php: 7.0
      env:
        - DEPENDENCIES=lowest

[andig]

Then for the sake of it lets to the same for the lowest supported version 5.3, too?

[andig]

What confuses me now is that on php 5.3 composer picks ringcentral/psr7:1.2 (which I wouldn't expect?) while on php 7.0 it chooses 1.0?

[jsor]

ringcentral/psr7:1.0 requires php: >=5.4.0 (thats why it can be picked by the PHP7 build), since ringcentral/psr7:1.2 it has been lowered to >=5.3, so that's the lowest version the PHP5.3 build can pick.

[andig]

Then something else is broken in the 7.0 build.

- Updating phpunit/phpunit (4.8.35 => 4.8.0) Downloading: Connecting... Downloading: 100%

$ ./vendor/bin/phpunit --coverage-text
PHPUnit v0.4.3-14-g8d2e2c9 by Sebastian Bergmann and contributors.

Since phpunit 4.8 is installed that might have been bogus- the version number definitely looks borked.

update should use 4.8.10 at least: https://github.com/sebastianbergmann/phpunit/blob/4.8.32/ChangeLog-4.8.md

[clue]

I'd like to look into getting the release out What is the status here? Do you think this PR is still needed?

IMHO we don't really need this, but I see no harm in adding this anyway if you feel that this adds value. 👍

Technically, each and every minor version of our dependencies could have introduced breaking changes, but I rarely see this being an actual issue and the latest version is regularly tested via CI. Also testing the lowest supported version adds some value, but ultimately if we'd want to be 100% sure we'd have to test every possible combination of our dependencies :-)

[andig]

The issue was at least obvious with ringphp and it shouldn't harm. Imho this pr is ready. Viele Grüße, Andreas

…

Am 13.02.2017 um 09:06 schrieb Christian Lück ***@***.***>: I'd like to look into getting the release out What is the status here? Do you think this PR is still needed? IMHO we don't really need this, but I see no harm in adding this anyway if you feel that this adds value. 👍 Technically, each and every minor version of our dependencies could have introduced breaking changes, but I rarely see this being an actual issue and the latest version is regularly tested via CI. Also testing the lowest supported version adds some value, but ultimately if we'd want to be 100% sure we'd have to test every possible combination of our dependencies :-) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[clue]

Alright, changes LGTM, can you rebase on current master now that #113 and #115 are in? 👍

[andig]

Will do, but to learn something: why is this necessary? Targeting different files here?

[clue]

Will do, but to learn something: why is this necessary?

The branch behind this PR is based on an older version of the master branch, one which did not specify the proper minimum version requirements. Hence, trying to test minimum versions on this branch does current fail, see e.g. Travis.

In the meantime, the master branch has been updated and we now specify proper minimum version requirements (#113 and #115). However, we do not currently run any tests on the master branch for older versions (and it's debatable whether this is needed in the first place).

If you rebase this branch on the current master, then this branch will use the proper minimum version requirements.

If we were to accept this PR now without rebasing on master first, then we risk accepting a PR that does technically not build currently, but will will build once it's merged.

I hope this helps 👍

[andig]

If we were to accept this PR now without rebasing on master first, then we risk accepting a PR that does technically not build currently, but will will build once it's merged.

Actually, I was assuming that retriggering the travis build (which anybody with sufficient privileges can do but not me) would apply it to current master and then test to get valid results. As said, really no problem and will do asap once I'm back at the machine.

[clue]

Thanks for keeping this updated! 👍

retriggering the travis build (which anybody with sufficient privileges can do but not me) would apply it to current master

This may be true from a practical (sane!) view point :-) I'm tempted to disagree from a theoretical view point, but I'm not really that much into discussing theoretical aspects of this, so I appreciate you've rebased this on current master already, which I still believe is the cleanest way of addressing this :-)

[WyriHaximus]

Awesome, thank you 👍