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 <smalys...@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"™. > > 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 > >
