Based on our recent discussion on #pecl , I'd like we clarify what we
think is a "BCB" (Backward Compatibility Break) as well as what "only
minor BC breaks" could mean.
Stas' recent topic on internals "On BC and interfaces" may serve as a
reflection basis.
As our release process told us that we should not add BCB (but only
"minor" ones ... hum) in any minor release (nor revision), and as 5.5
release process is going to start soon, I'd like we try to all agree
on that point.
What could be qualified as a BCB ?
Adding a new language function ? Removing one ?
Thoughts ?
Julien.P
2012/9/10 jpauli jpauli@php.net:
Based on our recent discussion on #pecl , I'd like we clarify what we
think is a "BCB" (Backward Compatibility Break) as well as what "only
minor BC breaks" could mean.
Stas' recent topic on internals "On BC and interfaces" may serve as a
reflection basis.
As our release process told us that we should not add BCB (but only
"minor" ones ... hum) in any minor release (nor revision), and as 5.5
release process is going to start soon, I'd like we try to all agree
on that point.What could be qualified as a BCB ?
Any modification that change the behaviour of an existing API?
Most of libraries change their minor version number when they add a
new interface, but they change their major number when an existing
interface is modified.
hi,
Based on our recent discussion on #pecl , I'd like we clarify what we
think is a "BCB" (Backward Compatibility Break) as well as what "only
minor BC breaks" could mean.
Change in phpinfo related stuff are minor. Adding a notice or warning
is minor or irrelevant. Changing return values (like suddenly
returning array instead of integer, f.e.), behaviors or similar things
are not allowed in x.y+1.
Stas' recent topic on internals "On BC and interfaces" may serve as a
reflection basis.
That's more about internals APIs, which is not what is meant in the
release RFCs for x.y+1 releases.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Pierre,
hi,
Based on our recent discussion on #pecl , I'd like we clarify what we
think is a "BCB" (Backward Compatibility Break) as well as what "only
minor BC breaks" could mean.Change in phpinfo related stuff are minor. Adding a notice or warning
is minor or irrelevant. Changing return values (like suddenly
returning array instead of integer, f.e.), behaviors or similar things
are not allowed in x.y+1.
I'm not so sure about that. Adding a warning or notice may actually cause a
lot of headaches. See what happened with call-time-pass-by-reference in
5.3... All of a sudden a lot of code that worked fine is flooding logs with
new warnings...
I guess my point is that the line between a BCB and a minor BCB is a
lot finer and a lot more subjective that it seems on the surface. Is adding
a new language feature with a new keyword a BCB (since existing
functionality using that keyword is now a parse error), or is it a minor
BCB since it doesn't change any existing built-in behavior (only adds new
behaviors)?
I think that's what we need to expand upon.
My take on it is this:
If you can solve the "break" using nothing but static analysis and a static
conversion "script", then it's a minor break. So new keywords would be fine
(you could find/replace function yield() with function yield2() really
easily). But changing the semantics of code (returning an array instead of
an int, changing how references are passed, etc) would require developer
interaction to fix, and as such would not be minor.
And one point on what classifies as a BC break: Everything. Any change will
break BC in some way. Even adding a function is a BC break since existing
code may use the same function names. Fixing a segfault is a BC break as
well, as it's changing the way it works. The difference comes in if it's a
minor BC break, or a major one. And that's not trivial...
My $0.02 at least...
Anthony
hi,
Pierre,
hi,
Based on our recent discussion on #pecl , I'd like we clarify what we
think is a "BCB" (Backward Compatibility Break) as well as what "only
minor BC breaks" could mean.Change in phpinfo related stuff are minor. Adding a notice or warning
is minor or irrelevant. Changing return values (like suddenly
returning array instead of integer, f.e.), behaviors or similar things
are not allowed in x.y+1.I'm not so sure about that. Adding a warning or notice may actually cause a
lot of headaches. See what happened with call-time-pass-by-reference in
5.3... All of a sudden a lot of code that worked fine is flooding logs with
new warnings...
it does not break code, also that happens only and only from 5.x to
5.x+1 and should not happen from 5.x.y to 5.x.y+1 for example (or on
very rare cases).
I guess my point is that the line between a BCB and a minor BCB is a lot
finer and a lot more subjective that it seems on the surface. Is adding a
new language feature with a new keyword a BCB (since existing functionality
using that keyword is now a parse error),
We add new features, that's no BC break as the feature did not exist
before. Keyword is a problem, but we have to live with for now.
My take on it is this:
If you can solve the "break" using nothing but static analysis and a static
conversion "script", then it's a minor break. So new keywords would be fine
(you could find/replace function yield() with function yield2() really
easily). But changing the semantics of code (returning an array instead of
an int, changing how references are passed, etc) would require developer
interaction to fix, and as such would not be minor.And one point on what classifies as a BC break: Everything. Any change will
break BC in some way. Even adding a function is a BC break since existing
code may use the same function names.
Why we added namespace, no issue (well for 5.3+ :).
Fixing a segfault is a BC break as
well, as it's changing the way it works.
That's really a totally wrong example.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Pierre,
it does not break code, also that happens only and only from 5.x to
5.x+1 and should not happen from 5.x.y to 5.x.y+1 for example (or on
very rare cases).
I agree it should not happen from 5.x.y to 5.x.y+1. But it definitely does
break code... Not all, but at least some...
I guess my point is that the line between a BCB and a minor BCB is a lot
finer and a lot more subjective that it seems on the surface. Is adding a
new language feature with a new keyword a BCB (since existing
functionality
using that keyword is now a parse error),We add new features, that's no BC break as the feature did not exist
before. Keyword is a problem, but we have to live with for now.
Well, for a very limited subset of features possible sure...
My take on it is this:
If you can solve the "break" using nothing but static analysis and a
static
conversion "script", then it's a minor break. So new keywords would be
fine
(you could find/replace function yield() with function yield2() really
easily). But changing the semantics of code (returning an array instead
of
an int, changing how references are passed, etc) would require developer
interaction to fix, and as such would not be minor.And one point on what classifies as a BC break: Everything. Any change
will
break BC in some way. Even adding a function is a BC break since existing
code may use the same function names.Why we added namespace, no issue (well for 5.3+ :).
Fixing a segfault is a BC break as
well, as it's changing the way it works.That's really a totally wrong example.
I chose it for that specific reason. The line is blurry if taken literally
(which many do)...
Anthony
I chose it for that specific reason. The line is blurry if taken literally
(which many do)...
It can't possibly be an absolute rule. If you take it completely
literally then we wouldn't be able to fix bugs either. Every change has
some effect that may or may not affect users.
I know we are mostly geeks here and geeks love structure and rules
without exceptions to fall back on so they don't have to think so much
and can end arguments simply by pointing at a set of hard rules everyone
follows. But this really doesn't work that well in the real world. The
real world isn't binary. It is a complicated analog world with many many
levels of gray between right and wrong, between minor and major BC break
and between peoples' expectations and their personal uses of PHP.
-Rasmus
I chose it for that specific reason. The line is blurry if taken literally
(which many do)...It can't possibly be an absolute rule. If you take it completely
literally then we wouldn't be able to fix bugs either. Every change has
some effect that may or may not affect users.I know we are mostly geeks here and geeks love structure and rules
without exceptions to fall back on so they don't have to think so much
and can end arguments simply by pointing at a set of hard rules everyone
follows. But this really doesn't work that well in the real world. The
real world isn't binary. It is a complicated analog world with many many
levels of gray between right and wrong, between minor and major BC break
and between peoples' expectations and their personal uses of PHP.
I'd like to point out two things here:
a) The current releaseprocess RFC 1 says that "Backward
compatibility must be kept" in minor version increments (5.4 -> 5.5).
Seeing the discussion above, may I rephrase this to "Only minor
backwards compatibility breaks allowed"? It seems that we agree that
smaller breaks are okay, just no big stuff. I think that's what was
meant all along there, but phrased a little bit too conservatively.
b) In the PHP 5.5 thread Pierre said the following:
There is o 5.5 branch, there is master. Master is the development
branch and as such can have such breakages. It does not mean that we
have these BC breaks in 5.5. 5.5 should be based on 5.4 with the
feature additions and improvements we want in, but definitively not
with BC breaks.
This is concerning me a bit. Does this mean that PHP 5.5 will be
branched off PHP 5.4 and we will then backport features from master?
If so, this would seem like a Very Bad Idea to me, from a purely
technical point of view. Unless I'm much mistaken this would have to
be done manually (git is of no help here) and would be a very tedious
and fragile business.
Before Pierre said that I was under the impression that PHP 5.5 will
be branched off master, which would make a lot more sense to me. Could
someone clarify how it will be done?
Hi!
This is concerning me a bit. Does this mean that PHP 5.5 will be
branched off PHP 5.4 and we will then backport features from master?
If so, this would seem like a Very Bad Idea to me, from a purely
technical point of view. Unless I'm much mistaken this would have to
I think also it's not a good idea, not sure what Pierre meant by that
though. So far I don't think we have anything BC-breaking in master, but
if we do we may have to split it in bc and non-bc branches.
Before Pierre said that I was under the impression that PHP 5.5 will
be branched off master, which would make a lot more sense to me. Could
someone clarify how it will be done?
I was assuming this too. I guess we need some clarification on what
Pierre was meaning.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
hi,
a) The current releaseprocess RFC [1] says that "Backward
compatibility must be kept" in minor version increments (5.4 -> 5.5).
Seeing the discussion above, may I rephrase this to "Only minor
backwards compatibility breaks allowed"? It seems that we agree that
smaller breaks are okay, just no big stuff. I think that's what was
meant all along there, but phrased a little bit too conservatively.b) In the PHP 5.5 thread Pierre said the following:
There is o 5.5 branch, there is master. Master is the development
branch and as such can have such breakages. It does not mean that we
have these BC breaks in 5.5. 5.5 should be based on 5.4 with the
feature additions and improvements we want in, but definitively not
with BC breaks.This is concerning me a bit. Does this mean that PHP 5.5 will be
branched off PHP 5.4 and we will then backport features from master?
If so, this would seem like a Very Bad Idea to me, from a purely
technical point of view. Unless I'm much mistaken this would have to
be done manually (git is of no help here) and would be a very tedious
and fragile business.
Before Pierre said that I was under the impression that PHP 5.5 will
be branched off master, which would make a lot more sense to me. Could
someone clarify how it will be done?
The idea of using 5.4 as base is to actually have a clue about what we break.
We do not have this clue in master and there are for sure non
acceptable BC breaks in master. They won't be in 5.5. I'd said before,
but every user I talk literally love this BC break policy. BC is the
most painful part for every hoster, framework developer or users. It
is also what prevents fast and smooth migration. We must be strict
here or 80% of the reasons why I pushed that release process RFC are
gone.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi!
We do not have this clue in master and there are for sure non
acceptable BC breaks in master. They won't be in 5.5. I'd said before,
Why don't we have a clue? We definitely do have a clue, we have git logs
and we know what went into master - it is not that old. Could you list
the non-acceptable BC breaks that are now in 5.5?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
We do not have this clue in master and there are for sure non
acceptable BC breaks in master. They won't be in 5.5. I'd said before,Why don't we have a clue? We definitely do have a clue, we have git logs
and we know what went into master - it is not that old. Could you list
the non-acceptable BC breaks that are now in 5.5?
Reading it does not tell me if something has changed from 5.4 to master/5.5.
However we can at least run against the 5.4 tests suite and compare,
see why tests fail etc. :)
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi!
We do not have this clue in master and there are for sure non
acceptable BC breaks in master. They won't be in 5.5. I'd said before,Why don't we have a clue? We definitely do have a clue, we have git logs
and we know what went into master - it is not that old. Could you list
the non-acceptable BC breaks that are now in 5.5?Reading it does not tell me if something has changed from 5.4 to master/5.5.
However we can at least run against the 5.4 tests suite and compare,
see why tests fail etc. :)
Btw, on a similar note, I would really appreciate if every change in
the internals APIs (additions, API changes, removals, etc.) as well as
the user land areas are documented in
https://github.com/php/php-src/blob/master/UPGRADING.INTERNALS and
https://github.com/php/php-src/blob/master/UPGRADING respectively.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi!
That's more about internals APIs, which is not what is meant in the
release RFCs for x.y+1 releases.
The idea though wasn't about internals APIs. The idea was that for users
it's better to have platform that they can expect to work with their
code 10 years after than to have a platform that you have to rewrite
your code each couple of years. PHP wasn't excellent about it in the
past, though there were very good reasons for that. But we need to start
thinking about how we can get it much better in the future. Including
thinking along the ways that each feature we add today will be set in
stone for next 10 years - so we better think 10 years or more ahead when
we do them. I know it's not easy and sometimes may be just impossible to
know that far in advance, but we should try to do our best.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
Change in phpinfo related stuff are minor. Adding a notice or warning
is minor or irrelevant. Changing return values (like suddenly
I'm not sure I agree about warning/notice. Depends if it's a clear bug -
either in our code (like, opening non-existing file produces warning but
opening it with another function does not) or in user code (like giving
wrong parameters to a function or calling it in a clearly wrong
context). If it's not than it actually may disturb working code so we
have to be careful. E.g., PHPUnit unit tests will drop out on any
unexpected warning. Some applications would do the same due to their
error handler structure.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
Based on our recent discussion on #pecl , I'd like we clarify what we
think is a "BCB" (Backward Compatibility Break) as well as what "only
minor BC breaks" could mean.
Stas' recent topic on internals "On BC and interfaces" may serve as a
reflection basis.
As our release process told us that we should not add BCB (but only
"minor" ones ... hum) in any minor release (nor revision), and as 5.5
release process is going to start soon, I'd like we try to all agree
on that point.
I think first we have to distinguish several levels of BC:
- Binary BC
- Source-level extension BC
- PHP Code (API) BC
Binary BC means that extension compiled with one version would work with
another without recompilation. We keep this level of compatibility
through all minor (5.x) releases and breaking it is an absolute no-no.
However, between minors (5.5 -> 5.5) breaking it is fine.
Source-level extension BC means that an extension may be successfully
compiled and working in two versions. We strive to keep it between
minors, though if absolutely necessary for implementing new stuff we may
occasionally break it. But this has to be kept to absolute minimum and
only done if there's absolutely no way to avoid it - e.g., if we
refactoring the engine to use more efficient way to generate opcodes and
we need to change zend_op_array structure, some extensions that use it
may be broken.
PHP Code BC means that a PHP script that works in one version also works
in another version. We should keep this level of BC across all major
version, and breaking it between minor versions is not acceptable. Only
exceptions may be: introduction of new keywords (may break code that
uses the same identifier), security fixes (if we have to introduce more
secure way of doing something, application using insecure practices may
be broken), bug fixes (if application relied on a buggy behavior of PHP
to work, it may be broken), removal of already deprecated features.
Adding new functions usually not considered BC break, though technically
it may break code that used the same function name.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
Based on our recent discussion on #pecl , I'd like we clarify what we
think is a "BCB" (Backward Compatibility Break) as well as what "only
minor BC breaks" could mean.
Stas' recent topic on internals "On BC and interfaces" may serve as a
reflection basis.
As our release process told us that we should not add BCB (but only
"minor" ones ... hum) in any minor release (nor revision), and as 5.5
release process is going to start soon, I'd like we try to all agree
on that point.I think first we have to distinguish several levels of BC:
- Binary BC
- Source-level extension BC
- PHP Code (API) BC
Binary BC means that extension compiled with one version would work with
another without recompilation. We keep this level of compatibility
through all minor (5.x) releases and breaking it is an absolute no-no.
However, between minors (5.5 -> 5.5) breaking it is fine.
Typo alert. That should say 5.4 -> 5.5 :)
-Hannes