Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75980
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.199 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
In-Reply-To: <3D49DA70-E726-439B-94E7-F8888358C04D@benramsey.com>
Date: Wed, 23 Jul 2014 22:27:48 +0100
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <98D1A77A-821D-49DE-A8EE-64E77DE2EFB4@ajf.me>
References: <CAESVnVq5P26Yi=w1yF3ETBEPe+PwJdEAuJ3-8Yw5vsQBy7ofDw@mail.gmail.com> <CAESVnVqGPkENTEN0VBQmgjPBGbZVNOUSvNa8XZVdg0aOCyd0WQ@mail.gmail.com> <53CFB2CD.5050703@hoa-project.net> <53D0062A.20905@gmail.com> <3D49DA70-E726-439B-94E7-F8888358C04D@benramsey.com>
To: Ben Ramsey <ben@benramsey.com>
Subject: Re: [PHP-DEV] PHP Language Specification
From: ajf@ajf.me (Andrea Faulds)


On 23 Jul 2014, at 21:59, Ben Ramsey <ben@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 =91reference =
implementation=92 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=92s =935.6-compliant=94 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 =935.6.1=94 specification when the =
problem was with one specific implementation?

I=92m 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=92d 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=92t 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=92re doing just now.

What are others=92 thoughts on this? Should we split into PHP spec =
versions and Zend PHP versions?

--
Andrea Faulds
http://ajf.me/