Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99285
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.162 cause and error)
MIME-Version: 1.0
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> <e441098f-9f04-c8bd-13b0-1fdcd3b08412@gmail.com>
In-Reply-To: <e441098f-9f04-c8bd-13b0-1fdcd3b08412@gmail.com>
Date: Tue, 30 May 2017 21:04:11 +0000
Message-ID: <CANUQDChC=ZdReoOXGbjnfgnnQ=CX0qNhckYB-HhXP3xbe8wNvw@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="001a113db9e4032ce80550c426ce"
Subject: Re: [PHP-DEV] Parameter type widening RFC
From: me@kelunik.com (Niklas Keller)

--001a113db9e4032ce80550c426ce
Content-Type: text/plain; charset="UTF-8"

Rowan Collins <rowan.collins@gmail.com> schrieb am Di., 30. Mai 2017, 19:39:

> 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.
>

>=min-php-version.

> 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?
>

Depends on the new minimum version. If it is 7.0 or 7.1, then it's a
breaking change so new major, otherwise new minor.

> 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
>

As scalar types do not work on PHP 5, why would I use that constraint?

> 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.
>

I don't see a reason to release a new major when increasing the minimum PHP
version requirement. The old major.minor can still get bug fixes but won't
receive new features.

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, Niklas

>

--001a113db9e4032ce80550c426ce--