On Fri, Oct 18, 2013 at 6:03 PM, Rowan Collins wrote:
seem like this wasn't the case, because they would collectively have been
6.0.
On 18/10/2013 15:51, Ferenc Kovacs wrote:
shouldn't really happen if you strictly follow the "new" release process
rfc was accepted: https://wiki.php.net/rfc/**releaseprocess<https://wiki.php.net/rfc/releaseprocess> ,
unfortunatelly it seems that there are some cases, when this can happen
(some bug fixes, but the biggest offender was dropping deprecated features
for 5.4.0 which were already removed in the 6.0 branch), but if you check
out http://hu1.php.net/manual/en/**migration55.incompatible.php<http://hu1.php.net/manual/en/migration55.incompatible.php> you
can see that the actual intentional BC breaks was really small, the only
non bugfix BC break was removing the php logo urls, which was never meant
to be a public api, but to be used by phpinfo().
Ah, I see. I guess it was the slew of changes in 5.3 and 5.4 which made itshouldn't really happen if you strictly follow the "new" release process
rfc was accepted: https://wiki.php.net/rfc/**releaseprocess<https://wiki.php.net/rfc/releaseprocess> ,
unfortunatelly it seems that there are some cases, when this can happen
(some bug fixes, but the biggest offender was dropping deprecated features
for 5.4.0 which were already removed in the 6.0 branch), but if you check
out http://hu1.php.net/manual/en/**migration55.incompatible.php<http://hu1.php.net/manual/en/migration55.incompatible.php> you
can see that the actual intentional BC breaks was really small, the only
non bugfix BC break was removing the php logo urls, which was never meant
to be a public api, but to be used by phpinfo().
seem like this wasn't the case, because they would collectively have been
6.0.
yeah, and don't forget that 5.3 was already released, and the 5.4 branch
was already created before the new release process rfc got voted and
accepted, so that was the main reason why those versions had more BC
incompatible changes.
So the aim is that a script made to work on PHP 5.4 will now be guaranteed
to run on any version <6, although some required modules might have moved
to PECL?
yeah, the current rfc promises that, plus there are some case-by-caseto run on any version <6, although some required modules might have moved
to PECL?
exceptions, mostly for bugfixing, plus it seems that introducing new
reserved keywords/class/method/constant names is not a BC break(would be
hard to introduce new features without that).
As a user, it is certainly not obvious that features discussed as being
removed "soon" will only actually disappear once there is a 6.0, because
there doesn't seem to be any reason to expect PHP 6 to be "soon".
removed "soon" will only actually disappear once there is a 6.0, because
there doesn't seem to be any reason to expect PHP 6 to be "soon".
Yeah, and I think(based on some mails and RFCs) that some people still
don't understand/accepted that BC breaks are highly unlikely to be accepted
to a minor release, but I think that people will wrap their heads around it.
Unless a release within the next few years is numbered 6.0 (or something
else >5) simply to clean up the deprecated functionality, without actually
including major changes like the Unicode string concept.
else >5) simply to clean up the deprecated functionality, without actually
including major changes like the Unicode string concept.
I think that the current tighter release cycle and stricter BC rules will
mean that there will be more frequent major releases than it was usual in
the past.
I also think that maybe we should even introduce new branches/concepts like
NEXT-MAJOR and NEXT-MINOR otherwise it will be a bit of a PITA to tell
whether we should have a major release next, as the master branch contains
a bunch of BC break changes, or that what changes should be reverted/not
merged when we branch out a new minor version.
But this topic should be discussed in a separate thread.
