There's something between the user level API and the ABI - which is source level compatibility.
What Dmitry's pointing out that if we commit to source level compatibility, it'll be quite limiting (based on past experience). If we don't commit to source-level compatibility then we're fine. I guess we can say we'll strive for source level compatibility, but not have it as a 'must'. Zeev > -----Original Message----- > From: Stas Malyshev [mailto:smalys...@sugarcrm.com] > Sent: Wednesday, June 01, 2011 7:51 PM > To: Dmitry Stogov > Cc: John Crenshaw; PHP internals > Subject: Re: [PHP-DEV] Final version, RFC release process > > Hi! > > > Before now each major (5.y+1) release introduced API changes. > > We just couldn't introduce literal tables, interned strings, etc > > without API changes. > > I think by API there it means PHP-level API, i.e. one exposed to the user, not > binary API exposed to the extensions, which is meant by ABI. > So what should be preserved is PHP function signatures, classes, syntax, INI > settings, etc. but internals can change. > > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > > -- > PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: > http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
