Feeling Lucky
?
?
[#9773] - phpunit/dbunit was only updated in some places
- Closed
- 6 Apr 2016
- Medium
- Build: staging
- # 9773
- Diff
- photodude:patch-5
- Success continuous-integration/travis-ci/pr The Travis CI build passed Details
User tests: Successful: Unsuccessful:
Pull Request for Issue phpunit/dbunit version was only updated in some places.
Summary of Changes
Updates composer files to be more consistent with phpunit/dbunit version listing
Testing Instructions
Travis CI jobs should complete with phpunit/dbunit still listing v1.4.1 after composer install, merge on code review.
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Labels |
Added:
?
?
|
||
| Labels |
Added:
?
?
|
||
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2016-04-06 22:51:20 |
| Closed_By | ⇒ | mbabker |
brianteeman
- | Category | ⇒ | External Library |
| Labels | |||
photodude
- comment
- 7 Apr 2016
Thank you for the additional explanation.
I'm going to close this PR because it's actually not correct but also I'll explain why.
First, the declared minimum dbunit version is ~1.3, unless we change the composer.json files to list the explicit versions that the CMS is shipping/using this is still acceptable (with that said does our unit test suite depend on anything in newer dbunit versions?).
Second, the change in the composer.lock file is invalid. Specifically, the line you changed comes from an auto-generated object from the Session package's dependencies. The 1.3.1 tag declares ~1.2 as the minimum, so the edit there actually causes the data for the included release to be incorrect.
Lastly, if you make a change to the composer.json file and run
composer updatethe hash and content-hash keys should be updated. They aren't here, which means you manually edited the lock file. Short of a merge conflict, you should never manually edit that file.