Prophecy.next and PHP version support

[ciaranmcnulty]

We've never had a second major version, and there are some issues:

• Maintaining support for older PHP is holding back what CI tools we can use (see Q&A improvements, fixes, phpstan and updates #430)
• Contributors get sad about older PHP still being supported (see Bumped php minimum version to 5.6 #419)
• There are some PHP features we've not even thought about leveraging (for instance, using anonymous classes for doubling)
• There are some areas where I think behaviour should change, that would be suitable for a major version (see Fix issue #120 by delaying unexpected method call evaluation #441)

I propose we adopt a public released date (probably in 2020) for Prophecy 2.0, with a higher version of PHP support at minimum and create a branch for it now. We can then target PRs that remove legacy code and introduce BC breaks to that branch.

We'd need to also make it clear what the support policy for Prophecy 1.0 was

I'd be happy to 'release manage' it.

@stof @everzet what do you think?

@sebastianbergmann Do you have any input here? PHPUnit is one of Prophecy's largest usage drivers (probably more than PhpSpec)

[stof]

(for instance, using anonymous classes for doubling)

this is a bad idea IMO. My own project has a memory issue related to Prophecy due to the number of mock class created (which can never be freed from memory due to the way PHP works). What I would like to work on (but never had the time for that) would be to force always using a cached doubler instead (to avoid create thousands of similar double classes during the testsuite run). Using anonymous classes would be opposite to that.

[stof]

Note that dropping support for dead PHP versions might even be done in a minor version, assuming that tools based on Prophecy don't depend on that support. PHPUnit maintained versions have already dropped them. What is the min PHP requirement of maintained PhpSpec versions @ciaranmcnulty ?

[ciaranmcnulty]

@stof Phpspec doesn't support <7.1 currently

I find version bumps during majors easier to handle but we can discuss

(mock class thing was an example, we'd need to profile that sort of change anyhow right)

[ciaranmcnulty]

Closing this, there wasn't any meaningful input on whether we should do it or not.