Re: Making "backwards compatibility" discussions more constructive

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 Wed, Nov 20, 2013 at 11:41 AM, Ferenc Kovacs <tyra3l@gmail.com> wrote: > 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 >