Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76778
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <53F637C5.1030006@sugarcrm.com>
References: <alpine.DEB.2.11.1408201003330.4107@whisky.home.derickrethans.nl>
	<53F637C5.1030006@sugarcrm.com>
Date: Thu, 21 Aug 2014 15:23:42 -0400
Message-ID: <CAHXmDMB=sLunFe5CbW62_RAP8x3WhtvZmgMh03YO8EvGuj2Ekw@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Derick Rethans <derick@php.net>, PHP Developers Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0111d1be9bc2e9050128a86c
Subject: Re: [PHP-DEV] On BC and not being evil (Was: Re: [PHP-DEV] [RFC]
 Integer Semantics)
From: rican7@gmail.com (Trevor Suarez)

--089e0111d1be9bc2e9050128a86c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

What if we were to *quantify* backwards compatibility in a way, as opposed
to just discussing the hypothetical BC breaking potential of a change?

I've never thought of this before, but this discussion had me thinking...
When I write a library that has a large user base, I try to write as many
unit tests and potential regression tests as possible. Unfortunately, the
larger the user base and the larger the feature set, the more coverage is
necessary. A language like PHP, it would be nearly unlimited. But stay with
me here. What's better than a simple unit of testing or benchmarking? Most
of us know that not much really beats real world application testing, or at
least a more realistic form of feature use.

This is where the Hack team got it right. Hack, during its early
development (and even still) used a suite of PHP frameworks, libraries, and
well known projects to test their PHP compatibility. Ironically, I believe
that Hack originally used these types of test due to a lack of a language
specification: there was no other way to really make sure to match the
language's behavior. However I think that this type of testing is valuable
anyway. What if we were to create a (or "borrow" Hack's) framework testing
suite and run PHP 7 and upcoming RFC patches against the suite before
accepting them.

Yes, likely things will fail with BC breaks, but then the PHP internals
team (or the RFC writer, hopefully) could then see exactly what was being
used in a given framework that might break. Even better, the internals/RFC
developer could see how much effort would be required to fix the BC break
in the broken tested framework and could gauge whether the break was
worthwhile or not a lot more. Finally, even more importantly, we could see
the range of libraries and frameworks that would break with a given change
and even introduce a potential RFC rule for BC breaking (on major versions,
etc)... like we have with rules around certain voting majorities based on
the type of language change, we could have a certain percentage of
libs/frameworks that would have to be compatible (or somehow quantify the
effort needed to update each [can it be automated via a tool or not]).

Anyway, just spit balling here. I know it would take effort, but this could
make a huge difference in our "oops" moments and quality checking for the
language updates. Hell, maybe it would even make us more apt to
"greenlight" features that we'd otherwise be afraid of because we'd see
that it wouldn't be as big of a deal as we thought.

Overall I think this would reduce a lot of the conjecture and
discussion/fear around possible BC breaks that could help or hurt the
project and the future of the language.

*Trevor Suarez*
+Trevor Suarez <https://plus.google.com/+TrevorSuarez>
@trevorsuarez <https://twitter.com/trevorsuarez>


On Thu, Aug 21, 2014 at 2:17 PM, Stas Malyshev <smalyshev@sugarcrm.com>
wrote:

> Hi!
>
> >> And since you're targetting the next major release, BC isn't an issue.
> >
> > This sort of blanket statements that "Backwards Compatibility is not an
> > issue" with a new major version is extremely unwarranted. *Extreme care=
*
> > should be taken when deciding to break Backwards Compatibility. It
> > should not be "oh we have a major new version so we can break all the
> > things"=E2=84=A2.
>
> I agree. Major means we *can* break BC, if there's a reason good enough,
> but that doesn't mean we get to break BC *for free*. We do need to
> carefully weight it each time and ensure it is worth it, not dismiss it
> with "oh, it's PHP 7, so we can do anything we want, BC is no longer a
> concern". We have millions of people using PHP 5, and the goal is for
> almost all of them to eventually use PHP 7, otherwise there's no point
> in it. Each BC break creates another hurdle on the way to it. We should
> take it seriously.
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--089e0111d1be9bc2e9050128a86c--