Re: [RFC] [Discussion] Deprecate functions with overloaded signatures

On Fri, May 12, 2023, at 6:52 AM, Rowan Tommins wrote: > I think it's actually very likely that voters would want to express > "deprecate, but do not remove before 10.0". Treating those votes as > "generally in favour, so enough to approve removal in 9.0" doesn't seem > appropriate. > > The other way around - "deprecate, but do not remove later than 9.0" - > seems less likely. I also don't see any reason to delay the deprecation > - the whole point of the longer period is to give people more notice. > > So I would suggest rewording the options slightly: > > a) Deprecate in 8.3, remove in either 9.0 or 10.0 > b) Deprecate in 8.3, remove in 10.0 > c) Do not deprecate > > Now if the votes are a:5, b:4, c:4, we can say: > > - 9 people voted for deprecation in 8.3, vs 4 against > - only 5 voted for removal in 9.0, vs 8 against > - 9 voted for removal in 10.0, vs 4 against > > So we conclude that we should deprecate in 8.3, and remove in 10.0 > > > The suggestion to narrow it down to a yes/no proposal in the discussion > phase is probably even better, though. Personally I'm on team "add new functions now, deprecate old ones in 9, remove old ones in 10." 1. As noted, it gives people a clean window in which to use the old or new ones without getting a deprecation warning, and without cutting off support for old but still supported PHP versions. 2. It gives people ample time to fix their code. (Around 7-8 years.) 3. Perhaps most importantly, it's a good-faith gesture to the people who have objected (validly, if sometimes impolitely and crudely) to shorter deprecation periods in the past. There is definitely a relationship building to be done with the broader user-space community, and offering a very wide grace period is a good way to help with that. That these particular functions and uses are quite rare doesn't really change any of that; if anything it strengthens it, that we're willing to be graceful about it even in cases where we could probably get away with not being so. --Larry Garfield