Making "backwards compatibility" discussions more constructive

Hi,

While I agree that in general maintaining backward compatibility is a good
thing, should there be a limit to how far that goes?

Refusing anything that causes a BC break except for major releases makes
sense, until you remember that PHP's major releases have a tendency to last
8-10 years if not longer. That's a pretty long time to wait for potential
enhancements / sane changes to the language isn't it?

There's the obvious point that security issues can be exempt from this
particular rule when necessary, and there have been various other breaking
changes (bug fixes or not) in minor point releases to date, but should /
could the requirement of no BC breaks for minor revisions be relaxed? Where
would the line be drawn? Personally, I have no idea.

Cheers.

hi,

On Tue, Nov 19, 2013 at 8:16 PM, Nikita Popov nikita.ppv@gmail.com
wrote:

Hi internals!

In a lot of the recent discussions (e.g. the HTTP_RAW_POST_DATA one) I've
seen the "we can't break backwards compatibility in PHP 5.x.y" argument
crop up again and again.

It is not an argument, but a rule we try to respect.

This rather unfortunate formulation takes root in the releaseprocess RFC
[1] and drives all discussions of BC issues into a non-constructive
direction.

As it can see as non constructive, the goal is to actually smooth and
speed up updates, be direct end users or ISPs.

Fact is that nearly all changes (by being changes...) break backwards
compatibility to some degree [2] and we do most certainly allow them in
both minor and bugfix releases. Whether they are allowed (and for what
version) depends on the severity (rather than existence) of the
breakage.

We have discussed that already. However I cannot compare new features,
keywords or functions as BC breaks. That's about namespaces or non
guarantee that a given keyword won't be used by PHP in later releases.

I would really appreciate it if we could move BC-related discussions away
from "Does it break BC?" (Yes, it does, in some way) to "How much does it
break BC and are we okay with that?"

Many small acceptable BC breaks do not allow one to update smoothly.
Reducing newer releases adoption rate and increase the common opinion
that all new releases cannot be used with current maintained PHP
applications. I would rather avoid introducing new reasons to support
this belief.

In the context of the HTTP_RAW_POST_DATA discussion this means thinking
about questions like a) how much code will be negatively affected, b) how
hard will it be for the code to be fixed and c) do the benefits in
performance, memory usage and/or functionality (significantly?) outweigh
the inconvenience of code-adjustments?

The "amount of code" affected can hardly be an argument. Especially
when we know that this code is actually used.

As some people have a hard time understanding that small BC breaks are
introduced routinely and intentionally, some examples of changes that are
considered "generally okay" for bugfix and minor releases:

Bugfix x.y.z -> x.y.(z+1):

Same as before, please explain why a bug fix can be considered as a BC
break.

• Addition of new functions, if the function name is unlikely to already
  be in (unconditional) use. E.g. the addition of getallheaders() for the
  built-in webserver in PHP 5.5.7.

Was it added in 5.5.x and not present in 5.5.0? That should not have
happened.

• Changes in the behavior of functions where a) the old behavior was
  considered buggy and b) not much code was relying on the old behavior
  (most
  bug fixes minus crashes fall into this category)

I disagree. Misbehavior must be fixed and it indeed can break BC if
some code relies on buggy behavior. But I do not see what wrong in
fixing bugs. It sounds pretty obvious to me, but if you have arguments
why we should re consider that (aka stop fixing bugs), please post
them :)

Minor x.y.0 -> x.(y+1).0

• Addition of new keywords, if the keyword is not commonly used in code
  already. (E.g. "yield", but not "user").
• Deprecation of functions or language features. In practice deprecation
  of heavily-used components like ext/mysql is one hell of a BC break,
  but
  we're okay with it for minor versions. (This also includes addition of
  other non-fatal errors)

Deprecation is a flag matters, more noises in the log is not
considered as a BC break.

• Removal of long-deprecated or little used functionality. E.g. the logo
  guid functions were removed in 5.5.

Right, that one is actually a BC break. I was not fund of it but
seriously I cannot imagine production code relying on that. That's why
it fits in the acceptable category.

• Changes in the behavior of the language where a) the old behavior was
  considered buggy and b) not much code was relying on the old behavior.

Same argument than the one for general bug fixes.

Thanks,
Nikita

PS: I think that it would be nice to adjust the releaseprocess RFC to
clarify this point, to make things clearer for both contributors and
end-users. The current promise sounds a lot like "You can just update
from
5.4 to 5.5 and won't need to make any code changes", but for any
non-trivial (legacy) codebase that's pretty far from the truth.

And that's exactly what we try to avoid. As it cannot be avoided 100%,
we should be closed to 100% and not "far away from any code
modification while upgrading".

We can make the RFC even more restrictive but then I'm not sure it
will be that productive, that will defeat your goals or ideas as well.

Cheers,

Pierre

@pierrejoye | http://www.libgd.org

hi,

On Tue, Nov 19, 2013 at 8:16 PM, Nikita Popov nikita.ppv@gmail.com
wrote:

Hi internals!

In a lot of the recent discussions (e.g. the HTTP_RAW_POST_DATA one) I've
seen the "we can't break backwards compatibility in PHP 5.x.y" argument
crop up again and again.

It is not an argument, but a rule we try to respect.

This rather unfortunate formulation takes root in the releaseprocess RFC
[1] and drives all discussions of BC issues into a non-constructive
direction.

As it can see as non constructive, the goal is to actually smooth and
speed up updates, be direct end users or ISPs.

Fact is that nearly all changes (by being changes...) break backwards
compatibility to some degree [2] and we do most certainly allow them in
both minor and bugfix releases. Whether they are allowed (and for what
version) depends on the severity (rather than existence) of the
breakage.

We have discussed that already. However I cannot compare new features,
keywords or functions as BC breaks. That's about namespaces or non
guarantee that a given keyword won't be used by PHP in later releases.

I would really appreciate it if we could move BC-related discussions away
from "Does it break BC?" (Yes, it does, in some way) to "How much does it
break BC and are we okay with that?"

Many small acceptable BC breaks do not allow one to update smoothly.
Reducing newer releases adoption rate and increase the common opinion
that all new releases cannot be used with current maintained PHP
applications. I would rather avoid introducing new reasons to support
this belief.

In the context of the HTTP_RAW_POST_DATA discussion this means thinking
about questions like a) how much code will be negatively affected, b) how
hard will it be for the code to be fixed and c) do the benefits in
performance, memory usage and/or functionality (significantly?) outweigh
the inconvenience of code-adjustments?

The "amount of code" affected can hardly be an argument. Especially
when we know that this code is actually used.

As some people have a hard time understanding that small BC breaks are
introduced routinely and intentionally, some examples of changes that are
considered "generally okay" for bugfix and minor releases:

Bugfix x.y.z -> x.y.(z+1):

Same as before, please explain why a bug fix can be considered as a BC
break.

• Addition of new functions, if the function name is unlikely to already
  be in (unconditional) use. E.g. the addition of getallheaders() for the
  built-in webserver in PHP 5.5.7.

Was it added in 5.5.x and not present in 5.5.0? That should not have
happened.

That's gonna be reverted.
Revisions are bug fixes only, new features should come to master and
eventually specific branches when discussed and accepted as is.
We cannot afford a new feature / function in revision anymore like we did
in the past, that's too dangerous and clearly out of our release process.

Julien Pauli

Hi,

Ferenc, that does seem like a good middle ground to me, though I think it
would have to be "guaranteed" that major releases would be on a 3 year
rolling schedule from the next major release.

My reasoning for this is that if a major release is delayed, then you have
confusion about when the 3 years starts from or end up with dates changing.
In addition, if a major version was to be skipped then, again, confusion
about when the next version is aimed for (3 years from decision to skip or
6 years from previous major release or something else?).

Just a thought.

On Tue, Nov 19, 2013 at 8:16 PM, Nikita Popov nikita.ppv@gmail.com
wrote:

Hi internals!

In a lot of the recent discussions (e.g. the HTTP_RAW_POST_DATA one) I've
seen the "we can't break backwards compatibility in PHP 5.x.y" argument
crop up again and again.

This rather unfortunate formulation takes root in the releaseprocess RFC
1 and drives all discussions of BC issues into a non-constructive
direction.

Fact is that nearly all changes (by being changes...) break backwards
compatibility to some degree 2 and we do most certainly allow them in
both minor and bugfix releases. Whether they are allowed (and for what
version) depends on the severity (rather than existence) of the
breakage.

I would really appreciate it if we could move BC-related discussions away
from "Does it break BC?" (Yes, it does, in some way) to "How much does it
break BC and are we okay with that?"

In the context of the HTTP_RAW_POST_DATA discussion this means thinking
about questions like a) how much code will be negatively affected, b) how
hard will it be for the code to be fixed and c) do the benefits in
performance, memory usage and/or functionality (significantly?) outweigh
the inconvenience of code-adjustments?

As some people have a hard time understanding that small BC breaks are
introduced routinely and intentionally, some examples of changes that are
considered "generally okay" for bugfix and minor releases:

Bugfix x.y.z -> x.y.(z+1):

• Addition of new functions, if the function name is unlikely to already
  be in (unconditional) use. E.g. the addition of getallheaders() for the
  built-in webserver in PHP 5.5.7.
• Changes in the behavior of functions where a) the old behavior was
  considered buggy and b) not much code was relying on the old behavior
  (most
  bug fixes minus crashes fall into this category)

Minor x.y.0 -> x.(y+1).0

• Addition of new keywords, if the keyword is not commonly used in code
  already. (E.g. "yield", but not "user").
• Deprecation of functions or language features. In practice deprecation
  of heavily-used components like ext/mysql is one hell of a BC break,
  but
  we're okay with it for minor versions. (This also includes addition of
  other non-fatal errors)
• Removal of long-deprecated or little used functionality. E.g. the logo
  guid functions were removed in 5.5.
• Changes in the behavior of the language where a) the old behavior was
  considered buggy and b) not much code was relying on the old behavior.

Thanks,
Nikita

PS: I think that it would be nice to adjust the releaseprocess RFC to
clarify this point, to make things clearer for both contributors and
end-users. The current promise sounds a lot like "You can just update
from
5.4 to 5.5 and won't need to make any code changes", but for any
non-trivial (legacy) codebase that's pretty far from the truth.

Hi Nikita,

Thank you for your feedback on the issue.
Personally I think that our current release process RFC only solves half of
the problem.
We were seeing slow adoption rates for new versions and also users
complaining about every second micro version breaking backward
compatibility (some of those concerns were ofc. magnified), but having the
current release process, which promises complying with the current best
practices, aka semantic versioning (http://semver.org/).
I think that the rfc should be a bit more descriptive/exact about what do
we mean by API/ABI BC break, and bugfix, but otherwise it is fine.
Additionally it is also defines the yearly release cycle, and the two+one
year support cycle, which is also quiet nice.
From the userland POV, we covered all the bases, you know what you can
expect from a release and when can you expect a new release.
What we didn't cover is the issue of the major versions.
Currently there is no way to plan any change which requires a BC break and
doesn't qualify as a bugfix.
This causes issues like:

• people are frustrated that there is no way to tell when or if a
  contribution will make it into a release if it requires a BC break
• which causes people to try and force/sneak in BC breaks into minor
  versions
• which causes additional stress and work to the RMs and those who are
  trying to follow the process, and also erodes the users trust in the new
  model when they see that we still don't follow the rules we put forward
  to
  ourselves.
• we don't have a place/branch to accept backward incompatible changes,
  because we have no way to tell beforehand, whether the next version
  will be
  a minor or major, everything goes into master, then we end up in a
  situation, when branching out the new minor version is a PITA, because
  it
  could have everything from master, except those dozend of commits which
  are
  related to that single backward incompatible change that we have there.

We had this discussion before, and I agree with Rasmus and co. that in an
open-source, volunteer-based project we can't really tell beforehand, that
what will be in the next version, before the work is actually done
(otherwise we end up with another PHP6, where there a bunch of promises
what should be there, and the release is stucked when some milestone
feature gets delayed/abandoned), but I do think that we could do stuff like
communicate that we can have a major release like in every 3 years, which
will be supported at least for 3 minor releases.
That way both the userland and the core developers could have some kind ETA
for getting there changes, and we could always skip/delay the major version
if there is nothing which would require a major release(albeit I don't
think that we would ever run short of backward incompatible changes).

tl;dr: I would like to stick with the current release process and don't
start using the previous bad process/exceptions as an excuse to keep adding
backward incompatible changes to our minor versions, but I would like to
extend the release process to cover the lifecycle of major versions.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

On Tue, Nov 19, 2013 at 8:16 PM, Nikita Popov nikita.ppv@gmail.com
wrote:

Hi internals!

In a lot of the recent discussions (e.g. the HTTP_RAW_POST_DATA one) I've
seen the "we can't break backwards compatibility in PHP 5.x.y" argument
crop up again and again.

This rather unfortunate formulation takes root in the releaseprocess RFC
1 and drives all discussions of BC issues into a non-constructive
direction.

Fact is that nearly all changes (by being changes...) break backwards
compatibility to some degree 2 and we do most certainly allow them in
both minor and bugfix releases. Whether they are allowed (and for what
version) depends on the severity (rather than existence) of the
breakage.

I would really appreciate it if we could move BC-related discussions away
from "Does it break BC?" (Yes, it does, in some way) to "How much does it
break BC and are we okay with that?"

In the context of the HTTP_RAW_POST_DATA discussion this means thinking
about questions like a) how much code will be negatively affected, b) how
hard will it be for the code to be fixed and c) do the benefits in
performance, memory usage and/or functionality (significantly?) outweigh
the inconvenience of code-adjustments?

As some people have a hard time understanding that small BC breaks are
introduced routinely and intentionally, some examples of changes that are
considered "generally okay" for bugfix and minor releases:

Bugfix x.y.z -> x.y.(z+1):

• Addition of new functions, if the function name is unlikely to already
  be in (unconditional) use. E.g. the addition of getallheaders() for the
  built-in webserver in PHP 5.5.7.
• Changes in the behavior of functions where a) the old behavior was
  considered buggy and b) not much code was relying on the old behavior
  (most
  bug fixes minus crashes fall into this category)

Minor x.y.0 -> x.(y+1).0

• Addition of new keywords, if the keyword is not commonly used in code
  already. (E.g. "yield", but not "user").
• Deprecation of functions or language features. In practice deprecation
  of heavily-used components like ext/mysql is one hell of a BC break,
  but
  we're okay with it for minor versions. (This also includes addition of
  other non-fatal errors)
• Removal of long-deprecated or little used functionality. E.g. the logo
  guid functions were removed in 5.5.
• Changes in the behavior of the language where a) the old behavior was
  considered buggy and b) not much code was relying on the old behavior.

Thanks,
Nikita

PS: I think that it would be nice to adjust the releaseprocess RFC to
clarify this point, to make things clearer for both contributors and
end-users. The current promise sounds a lot like "You can just update
from
5.4 to 5.5 and won't need to make any code changes", but for any
non-trivial (legacy) codebase that's pretty far from the truth.

Hi Nikita,

Thank you for your feedback on the issue.
Personally I think that our current release process RFC only solves half of
the problem.
We were seeing slow adoption rates for new versions and also users
complaining about every second micro version breaking backward
compatibility (some of those concerns were ofc. magnified), but having the
current release process, which promises complying with the current best
practices, aka semantic versioning (http://semver.org/).
I think that the rfc should be a bit more descriptive/exact about what do
we mean by API/ABI BC break, and bugfix, but otherwise it is fine.
Additionally it is also defines the yearly release cycle, and the two+one
year support cycle, which is also quiet nice.
From the userland POV, we covered all the bases, you know what you can
expect from a release and when can you expect a new release.
What we didn't cover is the issue of the major versions.
Currently there is no way to plan any change which requires a BC break and
doesn't qualify as a bugfix.
This causes issues like:

• people are frustrated that there is no way to tell when or if a
  contribution will make it into a release if it requires a BC break
• which causes people to try and force/sneak in BC breaks into minor
  versions
• which causes additional stress and work to the RMs and those who are
  trying to follow the process, and also erodes the users trust in the new
  model when they see that we still don't follow the rules we put forward
  to
  ourselves.
• we don't have a place/branch to accept backward incompatible changes,
  because we have no way to tell beforehand, whether the next version
  will be
  a minor or major, everything goes into master, then we end up in a
  situation, when branching out the new minor version is a PITA, because
  it
  could have everything from master, except those dozend of commits which
  are
  related to that single backward incompatible change that we have there.

We had this discussion before, and I agree with Rasmus and co. that in an
open-source, volunteer-based project we can't really tell beforehand, that
what will be in the next version, before the work is actually done
(otherwise we end up with another PHP6, where there a bunch of promises
what should be there, and the release is stucked when some milestone
feature gets delayed/abandoned), but I do think that we could do stuff like
communicate that we can have a major release like in every 3 years, which
will be supported at least for 3 minor releases.
That way both the userland and the core developers could have some kind ETA
for getting there changes, and we could always skip/delay the major version
if there is nothing which would require a major release(albeit I don't
think that we would ever run short of backward incompatible changes).

tl;dr: I would like to stick with the current release process and don't
start using the previous bad process/exceptions as an excuse to keep adding
backward incompatible changes to our minor versions, but I would like to
extend the release process to cover the lifecycle of major versions.

Hi

I agree that we keep telling people "no no I don't want to merge your patch
as it breaks BC", but we have no idea as when we'll release a new major ,
so that all those little patches can show up.

I agree with Ferenc, saying that we need to plan major releases.
For example, for 5.6 , we could also have branched a major, aka, a 6.0 ,
and break lots of things, like cleaning the INI settings like Yasuo says in
a reply to this topic.

We have new contributors, new ideas, new patch and code, running (but
breaking things). But, we have no idea about a new major, where we could
merge and release them...

So let's concentrate on an RFC update about our release process, clarifying
things about major release schedule.
The "3 years" thrown here might seem as a good basis.

Julien.Pauli