PHP 7.2 support, drop HHVM and PHP 5.5 + docs rebase

[michalbundyra]

Resolves #74

• dropped HHVM and PHP 5.5 support
• added PHP 7.2 support (travis builds and count fix - 633243f)
• updated PHPUnit
• rebased docs

This PR is based on #76 but with develop target.

[heiglandreas]

Thanks for this PR.

For my personal liking these are too many things in one PR!

Adding PHP7.2 is one thing, Removing HHVM and PHP5.5 a second, rebasing the docs is a third and updating PHPUnit is a fourth.

Would you mind splitting that up into several PRs?

[michalbundyra]

@heiglandreas All these changes are connected, if I start splitting it into separate PRs I'll create 4 conflicted PRs and then it will be even harder to merge it. For example I can't update to PHP 7.2 without updating PHPUnit. Please have a look on changes and you will notice that there is nothing surprising and reviewing it is quite simply.

PR now is ready to merge, tests pass and the main goal is reached - PHP 7.2 support.

[heiglandreas]

AFAIK PHPUnit update doesn't need PHP7.2 but can be done regardeless of that. And dropping PHP5.5 and HHVM is unrelated to the rest as well as the docs part.

Having 4 PRs that are based on one another is also a possibility.

Especially as the related Issue is only about the PHP7.2 support.

[michalbundyra]

@heiglandreas One more time: I can't add PHP 7.2 support without update PHPUnit - PHPUnit 4 is not compatible with PHP 7.2.

I can drop PHP 5.5 and HHVM in separate PR but then I have to update there also travis configuration and it will be conflicted.

Sorry, I did tons PRs like that and I think it's much simpler to have it all together tested and confirmed that all is good. You can see for example:

• PHP 7.2 + QA Tools + Docs - follow up #24, #26, #28, #33 zend-json#35
• PHP 7.2 + QA Tools + Docs + drop hhvm  zend-filter#61
• PHP 7.2 + QA Tools + Docs - follow up #8, #12, #13, #14 zend-dom#19
  ... and I can list 50 PRs more.

If you are the maintainer of the repository and you are not going to accept this PR feel free to close it. I'm not going to split it into smaller PRs just to have tons of conflicted PRs and multiple issues with resolving these conflicts.

[froschdesign]

@heiglandreas

1. @webimpress do this for many more repositories (!)
2. these changes are only improvements of the infrastructure

In my opinion, we should not make the work for @webimpress more complicated!

[michalbundyra]

@froschdesign

In my opinion, we should not make the work for @webimpress more complicated!

Thanks a lot. I'm happy that these is still someone who can understand me...

[heiglandreas]

@webimpress Thanks again for this PR. I'll review it later today anyhow. And I'm absolutely understanding you that it is easier to do thins in one PR. Nevertheless there are a lot of changes cluttered into one file regarding different tasks.

@froschdesign the changes do not only affect the infrastructure. Otherwise there wouldn't be changes to tests that need to be reviewed. Without them I wouldn't bother.

[heiglandreas]

And I would be able to review small PRs without an issue in between some tasks. For this PR I need dedicated time due to the size…

[michalbundyra]

@heiglandreas Again: feel free to close it and wait until somebody else will do it as you want.

I'm sure you will lose more time on merging and resolve conflict with smaller conflicted PRs than reviewing that one, where there is nothing really to review...

[heiglandreas]

@webimpress

Thanks a lot. I'm happy that these is still someone who can understand me...

It really make me sad that it is necessary to get personal when all we are talking about here is the code.

If you feel that suggesting splitting up a PR concerning more than 40 files and including separate unrelated topics is a personal insult then I'm really sorry about that. It has nothing to do with you as a person but with the content of the PR. And I think I tried to explain why I suggested splitting up the PR from a technical POV. And it was a suggestion, not a need to do.

[michalbundyra]

@heiglandreas check the files and changes, not the number of files... We are wasting time on arguing about nothing, when all changes are straight forward.

[froschdesign]

@heiglandreas
The review is quite simple and done quickly:

Two fixes in code:

• one change of order in namespace
• fix for 7.2 compatibility

Changes in test:

• switch from PHPUnit_Framework_TestCase to TestCase
• switch from assertEquals to assertCount for simplification
• import of namespaces
• BC change for PHPUnit_Util_ErrorHandler
• usage of expectException and expectExceptionMessage

Docs, Readme, Travis, Composer, PHPUnit etc.:

• usage of the templates from zendframework/maintainers

And all is done in separate commits.

[froschdesign]

@heiglandreas
Please don't get me wrong, I am also not a fan of all-included and full-stack PR's or commits! Given the fact that @webimpress will do this for almost repositories, I see this as pragmatic.

@webimpress
😉