Hi,
I am reading the 5.4 vs 7.0 debate. And, here's something I really
need to follow up on: "We should reserve major versions for BC breaks.
Just like we've always done". If that's what you've always done then
it's not PHP I spent practically every awake minute in the last seven
or so years.
If backwards compatibility break would mean a new PHP major we would
be in somewhere PHP 43 or something :D
Seriously. From PHP x.y.z to PHP x.y.z+1 things can change in ways
that require code change. That's in my books a backwards compatibility
break. Sometimes major ones. The biggest one, I think, was the order
change of session write / close handlers vs destructors in 5.0.5. I
also remember minor versions adding new arguments that can't be passed
in code running on older PHP because unlike userspace functions, these
complain about extra arguments. (Wish I remember what it was.
stream_wrapper_register with flags being new in 5.2.4? Would need to
dig in our archives a bit.)
Do not think I am trying to criticize PHP development. I am aware its
an open source software and scratch my own itch or get lost. I
remember debating a bit about backwards compatibility on this list but
I still couldnt resist writing this mail. I just wanted to make sure
this argument is not used in the PHP 5.4 vs 7.0 'cos it's totally
invalid and never was valid in the first place.
tl;dr the PHP developers have a false belief in not breaking backwards
compatibility in minor releases.
Regards
Karoly Negyesi
Hi,
I am reading the 5.4 vs 7.0 debate. And, here's something I really
need to follow up on: "We should reserve major versions for BC breaks.
Just like we've always done". If that's what you've always done then
it's not PHP I spent practically every awake minute in the last seven
or so years.If backwards compatibility break would mean a new PHP major we would
be in somewhere PHP 43 or something :DSeriously. From PHP x.y.z to PHP x.y.z+1
tl;dr the PHP developers have a false belief in not breaking backwards
compatibility in minor releases.
No, but there are way too many possibilities to break things without
us even noticing it.
That's why we proposed the release process and rules RFC:
http://wiki.php.net/rfc/releaseprocess which clearly disallow BC
breaks in bugs fixes releases. Given that we have a way to actually
test releases efficiently.
We constantly work to improve QA as well, it is also why I asked for
apps and frameworks authors or QA lead to get in touch to see how we
can have your tests valid our changes.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
tl;dr the PHP developers have a false belief in not breaking backwards
compatibility in minor releases.
Besides from what Pierre said: There is a difference between the
language and the function library. The change in the language from PHP 3
to PHP 4 was big - even trivial things like "include" and "require"
hanged their behavior. From PHP 4 to PHP 5 the whole object model
changed. PHP 6 once was supposed to change the whole type system by
introducing a new default string type. These are the kinds of changes
demanding the version change as they affect each and every user and
demanding big changes to applications.
Yes even with minor releases we do allow language changes which have
some BC impact but that's quite manageable and should allow a quick
migration path (5.3 introduced "goto" and "namespace" as keyword which
broke applications using them, the next version will introduce a keyword
"traits")
With bug fix releases the language is stable.
Talking about the function library there is more change for multiple
reasons. We /try/ not to break anything in bug fix releases. Sometimes
trying is not enough. For one there are cases where there are big bugs
which demand being fixed while changing the behavior (we have little
choice for instance in areas related to security ...) and sometimes
there are oversights. We are human and PHP is complex and our tests
can't cover all use cases, there we can try to do our bust but still
depend on everybody testing their applications (did YOU test 5.2.15RC1
and 5.3.4RC1, yet?) and use cases.
johannes