Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99267
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.178 as permitted sender)
To: internals@lists.php.net
References: <CADqTB_jB2ic4jx84HXVBPDr2qbP-DnXe782quKwc6o-ERpJJVw@mail.gmail.com>
 <CANUQDCjpjz8Wret1D6q9wb8rfBH4Xqc4uDqLTtuptkUdesUK4g@mail.gmail.com>
 <CADqTB_gbhw+pr+8dpkwdFwRTjiY4pk6fyeTnLUv72fBjTpArZA@mail.gmail.com>
 <CA+kxMuS=xBVQdyObpU2yK1jtr+3=JmAPJK-DaRKCZdCZRCfp2w@mail.gmail.com>
 <CADqTB_hs85GU63D5pB7ArHBhJ=0CK_aUYtPiOvokn4OeyFXTRA@mail.gmail.com>
 <CANUQDChF3BVkBUH7BOjXwNQapvzBQHwExZMQbeRYpn44jcCXfA@mail.gmail.com>
 <CADqTB_gc9BJnhL7fE-w51dYX760GSGsu6Vhc2d=DStLWRKXLRA@mail.gmail.com>
 <CA+kxMuSgz5EEhfO6dgTtCL=TiYw2ZraH88xKb17Vj9yFgdzr2Q@mail.gmail.com>
 <CADqTB_grvLXm9RrCdcKhJTA_J2+sG3WXNdzeB4jnteneNCxhQQ@mail.gmail.com>
Message-ID: <e441098f-9f04-c8bd-13b0-1fdcd3b08412@gmail.com>
Date: Tue, 30 May 2017 18:39:07 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CADqTB_grvLXm9RrCdcKhJTA_J2+sG3WXNdzeB4jnteneNCxhQQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Parameter type widening RFC
From: rowan.collins@gmail.com (Rowan Collins)

On 30/05/2017 07:24, Rasmus Schultz wrote:
>> The type widening RFC makes it easier to move to parameter types for
> existing libraries.
>
> I'm curious to see how you'll set the version constraint in your
> composer.json file.
>
> After adding a scalar type-hint to an interface, which is a breaking change
> in 7.0 and 7.1, but a non-breaking change in 7.2, is the new version of
> your package a major or minor release?
>
> If you release it as minor, you'll need a PHP version constraint like
> "^5.5, ^7.2", but excluding 7.0-7.1 In that way is itself a breaking
> change, so likely your only practical move is to release (and commit to
> maintain!) both major and minor versions, which doesn't sound easy at all.

That's a good point, and reduces the immediate value of the change 
slightly, but there is perhaps still value in making upgrading *easier* 
on users.

For instance, you might want to use some other feature of PHP 7.2 
anyway, so be willing to set that as your minimum version, but still not 
want users to have to go through checking all their code for the correct 
type hints. If they're already using 7.2, they might be able to migrate 
to your new version without changing a single line of code.

Regards,

-- 
Rowan Collins
[IMSoP]