Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70235
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain jonstirling.co.uk from 209.85.217.170 cause and error)
MIME-Version: 1.0
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: Wed, 20 Nov 2013 11:59:42 +0000
Message-ID: <CAPgKKxXz9fg=WAKcCLt0yCu-uNZKg00sZtEU-guh4dH8dKSYBw@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=001a11c3b9a435a11f04eb9a8478
Subject: Re: [PHP-DEV] Making "backwards compatibility" discussions more constructive
From: phoenix@jonstirling.co.uk (Jonny Stirling)

--001a11c3b9a435a11f04eb9a8478
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 RF=
C
> > [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 aw=
ay
> > 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) h=
ow
> > hard will it be for the code to be fixed and c) do the benefits in
> > performance, memory usage and/or functionality (significantly?) outweig=
h
> > 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 a=
re
> > 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 alrea=
dy
> > 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 cod=
e
> > already. (E.g. "yield", but not "user").
> >  * Deprecation of functions or language features. In practice deprecati=
on
> > 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 lo=
go
> > guid functions were removed in 5.5.
> >  * Changes in the behavior of the language where a) the old behavior wa=
s
> > 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 th=
e
> 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 an=
d
> 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 n=
ew
>    model when they see that we still don't follow the rules we put forwar=
d
> 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 whic=
h
> 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, tha=
t
> 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 li=
ke
> 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 E=
TA
> for getting there changes, and we could always skip/delay the major versi=
on
> 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 addi=
ng
> 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=E1cs
> @Tyr43l - http://tyrael.hu
>

--001a11c3b9a435a11f04eb9a8478--