Re: [RFC] [Discussion] Deprec ate functions with overloaded signatures

On 11 May 2023 18:06:44 BST, Dan Ackroyd <Danack@basereality.com> wrote: >On Thu, 11 May 2023 at 10:36, Tim Düsterhus <tim@bastelstu.be> wrote: >> >> I believe this vote format ("three options") is not really compatible >> with the voting rules (https://wiki.php.net/rfc/voting). >> >> For example it's not entirely clear what would happen here: >> >> 5 votes to deprecate in 8.3 / remove 9.0 >> 4 votes to deprecate in 9.0 / remove 10.0 >> 4 votes to not deprecate. > >The RFC author could just say that yes votes for deprecation and >eventual removal will be added together, with the timescale being a >preference vote. > >I think the only people who would object to that are people who would >vote yes to "deprecate and remove" but only if it matches their >preferred timescale, and would otherwise vote no. Which probably isn't >a thing. 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. Regards, -- Rowan Tommins [IMSoP]