On 23 Jul 2014, at 21:59, Ben Ramsey <b...@benramsey.com> wrote: > This got me thinking about the whole version number debate. With a language > specification, to what does the version number refer? The state of the > language specification, or the state of a given implementation of the > specification? Right now, the number refers to the state of the PHP Group > implementation, and implementations like HippyVM and HHVM say that they are > compatible with Zend PHP 5.x. Will we version the language specification > separately, and individual releases of various implementations (including the > PHP Group implementation) will state that they are compatible with version X > of the specification?
As I see it, Zend PHP will continue to be the ‘reference implementation’ of sorts, though we might see a shift to the point where the specification defines the semantics, not Zend PHP. 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? I’m not really a fan of having different versions of the PHP spec and Zend PHP, they should match up IMO. However, we run into the previously described problem. Perhaps we should switch to having four numbers: major, minor, micro and nano. Major, minor and micro would be reserved to the specification, and nano would be reserved for Zend PHP. So you’d have Zend PHP 5.6.0.1 which might fix a bug but implements the 5.6(.0) spec, and you might have the PHP 5.6.1 spec version which fixes an error in the specification or adds a minor version. Another option is to use a dash to separate things. specification-implementation, so 5.6.0-1 for the second Zend PHP implementation of the 5.6.0 spec, and 5.6.1-0 for the first Zend PHP implementation of the 5.6.1 spec. Actually, it occurs to me now that having micro versions of the spec is probably not a good idea and we should just keep to the de facto current scheme of only adding features in minors and only fixing bugs in micros. That way the spec doesn’t need a third number, and we can just reserve that third digit to the release of Zend PHP, which lines up nicely with what we’re doing just now. What are others’ thoughts on this? Should we split into PHP spec versions and Zend PHP versions? -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
