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.
>
> [1]: https://wiki.php.net/rfc/releaseprocess
> [2]: http://xkcd.com/1172/
>
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