On Fri, Oct 18, 2013 at 6:03 PM, Rowan Collins rowan.collins@gmail.com
wrote:
shouldn't really happen if you strictly follow the "new" release process
rfc was accepted: https://wiki.php.net/rfc/**releaseprocesshttps://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.phphttp://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 byphpinfo().Ah, I see. I guess it was the slew of changes in 5.3 and 5.4 which made it
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-case
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".
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.
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.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
On Fri, Oct 18, 2013 at 6:03 PM, Rowan Collins rowan.collins@gmail.com
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 byphpinfo().Ah, I see. I guess it was the slew of changes in 5.3 and 5.4 which made
it
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-case
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).
I think the general interpretation of that passage is "Only minor BC breaks
possible". I.e. BC breaks only in uncommonly used functionality (removal of
logo functions) or changes with little "direct" impact (like deprecation,
which usually is super-annoying for people, but can be turned off if you
want).
Nikita
On Fri, Oct 18, 2013 at 6:03 PM, Rowan Collins rowan.collins@gmail.com
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>; youcan 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 byphpinfo().Ah, I see. I guess it was the slew of changes in 5.3 and 5.4 which made
it
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-case
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).I think the general interpretation of that passage is "Only minor BC
breaks possible". I.e. BC breaks only in uncommonly used functionality
(removal of logo functions) or changes with little "direct" impact (like
deprecation, which usually is super-annoying for people, but can be turned
off if you want).Nikita
The rfc shouldn't really leave place for the interpretation.
I agree that the general consensus is that introducing new
notices/warnings/etc. is not a BC break.
The removal of the logo functions was a BC break, even thought that
probably didn't affect too many people (I have seen at least one person on
twitter mentioning using those functions), so that was against the rules of
the relese process RFC.
If we want to keep that kind of liberty, the RFC should be updated to
reflect that.
But I want to discuss another thing from my initial mail, the next-minor
branch. Now that it seems to be "official" that we will be the RMs for 5.6,
we were talking about creating the branch, which is still a PITA, because
we can (and will) have backward incompatible changes in master, which means
that we either have to branch the next minor version from master and (find
then)revert the BC breaks from the newly created branch, or we could branch
from 5.5 then cherrypick everything (500+ commits) except the offending
ones.
For now, I guess we will go with the branch from master, but for future
versions, it would be really nice if we could introduce a new branch,
PHP-5-NEXT, where you can commit anything which can be released with the
next php 5.x version.
(Yes, this means that instead of 5.3(sec only) -> 5.4 -> 5.5 -> 5.6 ->
master you have to do PHP-5.3(sec only) -> PHP-5.4 -> PHP-5.5 -> PHP-5.6 ->
PHP-5-NEXT -> master)
But this would allow us to always keep track of that what kind of changes
do we have BC wise, and can help us decide whether a minor or a major
release is appropriate, plus creating a new version would be always
straight forward: branch from PHP-5-NEXT for a minor, branch from master
for a major version.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu