Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:74955 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 37546 invoked from network); 17 Jun 2014 18:07:40 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 17 Jun 2014 18:07:40 -0000 Authentication-Results: pb1.pair.com header.from=tyra3l@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=tyra3l@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.54 as permitted sender) X-PHP-List-Original-Sender: tyra3l@gmail.com X-Host-Fingerprint: 209.85.192.54 mail-qg0-f54.google.com Received: from [209.85.192.54] ([209.85.192.54:32854] helo=mail-qg0-f54.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id B6/B6-00242-AE380A35 for ; Tue, 17 Jun 2014 14:07:39 -0400 Received: by mail-qg0-f54.google.com with SMTP id q107so331932qgd.13 for ; Tue, 17 Jun 2014 11:07:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kMiL+nvGJrdy80lfM5WjEIYd9/UihOVmxaDXDTK99fU=; b=ulRd9rWZM1kfphGqlxKKIizphl4FxMq6R3Dzbie3nSyD6TykIROahGmGR4KOF30ELU wT+cd5oLC5ow0kmN2DaanBGQK52Y6EhpLJs4f2uOivRCvX8jGc5KtOQ8ZvG7sAt47mwA MMrvH3/fyzGuelM9ziaL98MNqN3aQ0MSTn/d7iZVIg7Y1buNlDTKwpRbOm/Cj9RhuWXB jS4paTuXgsfEYapK0kB+ocjHbJ1tBBddO3uWatc5gPP9JcwGRf7hDQZbmkE97gAVBFPl mvqALMNBAw36kTCtMNejtflOBduM0bAjTXB8Fr3q3zt9z4VCQTMjHRC//fr73+MOP0Sb Zs4A== MIME-Version: 1.0 X-Received: by 10.140.91.226 with SMTP id z89mr34462560qgd.65.1403028456221; Tue, 17 Jun 2014 11:07:36 -0700 (PDT) Received: by 10.140.17.77 with HTTP; Tue, 17 Jun 2014 11:07:36 -0700 (PDT) In-Reply-To: References: <53886F73.70402@php.net> <1401810913.2282.81.camel@guybrush> <538DFEB1.7030207@fedoraproject.org> <538EAD75.5020402@fedoraproject.org> <539B0888.9040208@fedoraproject.org> Date: Tue, 17 Jun 2014 20:07:36 +0200 Message-ID: To: Pierre Joye Cc: Rafael Dohms , Marco Pivetta , Remi Collet , internals Content-Type: multipart/alternative; boundary=001a113a73a2be9cf804fc0c0401 Subject: Re: [PHP-DEV] BC break in 5.4.29 and 5.5.13 From: tyra3l@gmail.com (Ferenc Kovacs) --001a113a73a2be9cf804fc0c0401 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jun 17, 2014 at 7:24 PM, Pierre Joye wrote: > On Tue, Jun 17, 2014 at 3:49 PM, Ferenc Kovacs wrote: > > > generally BC breaks are not allowed in micro versions, but this doesn't > > mean that we can't change existing behavior in micro versions. > > currently there are 3 cases where we have precedence changing behavior = in > > micro versions: > > > > - bugfix > > - changing (explicitly) undefined behavior > > - introducing a new class/function/method/constant (I don't like thi= s, > > but it seems that it is the consensus seems to be that this is okay)= . > > It is definitively not OK. I cannot imagine any feature that cannot > x.y+1, which happens less than a year later. > > I agree with you, however the facts shows differently: http://php.net/ChangeLog-5.php#5.5.11 OPCache: Added function opcache_is_script_cached(). And even the releaseprocess rfc is written in a way, which implies that introducing new features are not considered as BC breaks: https://wiki.php.net/rfc/releaseprocess x.y.z to x.y+1.z Bugfixes *New features*Extensions support can be ended (moved to pecl) *Backward compatibility must be keptAPI compatibility must be kept (userland)* ABI and API can be broken (internals), src compatibility should be kept if possible, while breakages are allowed --=20 Ferenc Kov=C3=A1cs @Tyr43l - http://tyrael.hu --001a113a73a2be9cf804fc0c0401--