On 23/07/2014 22:27, Andrea Faulds wrote:
For majors and minors things are quite clear-cut. Zend PHP 5.6 implements PHP 5.6 as specified, and I imagine that HHVM foo.bar is going to say it’s “5.6-compliant” or something of the sort. The problem is micro versions. 5.6.1 is probably going to be a bug fix release, but why would there be a “5.6.1” specification when the problem was with one specific implementation?
[For clarity, the below refers to 3-part version numbers as Major.Minor.Patch, per http://semver.org]
We can probably assume (or even mandate!) that any change that required a change to the specification would need to be in a new minor version of Zend PHP, whereas changes in patch releases would be either specification-neutral, or fixing bugs in the implementation to better match the specification.
That means that the specification itself would only need a major.minor version, e.g. "PHP Specification 5.6" would correspond to the behaviour of all Zend PHP 5.6.x releases.
There might, however, be bugs in the specification itself, which would require additional editorial eleases which were better attempts to describe the same functionality. To make clear that these don't correspond with the patch releases of the code, a different convention could be used, e.g.: "5.6r1" ("PHP Specification 5.6, revision 1"); or "5.6a".
Alternatively, it could start fresh from 1.0, and then approximately track releases, in the same way that we have Zend Engine 2, not 5 (I'm guessing phpng, if accepted, will be Zend Engine 3?). I think the "backwards compatibility" of being able to say "PHP 5.6 compliant" is attractive though.
-- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
