Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70257
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.170 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <CAH-PCH7k_OuxCyhGsUYcX4Nd7SFLQK3r7squpSkKMo=znyO3aA@mail.gmail.com>
References: <CAF+90c_zyAr7kRnY9FArehhJ-QUxA-6B4TqNUx2Bzxwumbr1zA@mail.gmail.com>
 <CAH-PCH7k_OuxCyhGsUYcX4Nd7SFLQK3r7squpSkKMo=znyO3aA@mail.gmail.com>
Date: Thu, 21 Nov 2013 11:59:21 +0100
Message-ID: <CAMUwpuQiOFv_+A8bWmKUW8qrbWjpJOOxmZ5LP0kFjrBE2jbw1Q@mail.gmail.com>
To: Ferenc Kovacs <tyra3l@gmail.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113378d8cbe43204ebadcced
Subject: Re: [PHP-DEV] Making "backwards compatibility" discussions more constructive
From: jpauli@php.net (Julien Pauli)

--001a113378d8cbe43204ebadcced
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Nov 20, 2013 at 12:41 PM, 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.


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

--001a113378d8cbe43204ebadcced--