On Wed, Jun 7, 2017 at 5:38 PM, Rowan Collins <rowan.coll...@gmail.com> wrote:
> On 7 June 2017 15:23:13 BST, "Pedro Magalhães" <m...@pmmaga.net> wrote: > >On Wed, Jun 7, 2017 at 4:07 PM, Rowan Collins <rowan.coll...@gmail.com> > >wrote: > > > >> you can't simply pass something that *incidentally* changes a > >> pre-established rule > > > > > >Hi Rowan, > > > >Would you consider that that is not the case for your own RFC? > >https://wiki.php.net/rfc/deprecate-bareword-strings > > > I'm sorry, I don't follow. What rule is broken, incidentally or > explicitly, by that RFC? > > > -- > Rowan Collins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > The page that was already mentioned on this thread: https://wiki.php.net/rfc/releaseprocess#releases_cycle explicitly states the following: x.y.z to x.y+1.z > Backward compatibility must be kept However, a number of already implemented RFCs for 7.2 do not follow that rule strictly: - https://wiki.php.net/rfc/number_format_negative_zero - https://wiki.php.net/rfc/convert_numeric_keys_in_object_array_casts - https://wiki.php.net/rfc/deprecate-bareword-strings - https://wiki.php.net/rfc/get_class_disallow_null_parameter - https://wiki.php.net/rfc/counting_non_countables - https://wiki.php.net/rfc/deprecate-png-jpeg-2wbmp - https://wiki.php.net/rfc/hash-context.as-resource - https://wiki.php.net/rfc/deprecate-and-remove-intl_idna_variant_2003 - As well as some of the RFCs still pending implementation I don't mean at all that these should not have been accepted. Especially the ones that initiate a deprecation phase. But it is seems to me that this RFC does not break any rule that has been upheld strictly up to this point. Regards, Pedro
