> > 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 >
While this vote format looks a bit confusing for me at the first sight, I'm OK to apply it. Although, I don't fully agree with the "deprecate in 8.3 and remove in 10.0" part due to the reason I wrote about in my previous email. In my opinion, if we want to keep a signature for around 5-7 more years then we should really wait ~2 years with the deprecation so that people can react voluntarily first. Libraries have to get rid of deprecated calls in any case, otherwise their users will surely start to complain. If they do fix these calls in their PHP 8.x compatible code then there's much less reason to postpone the removal with 5 more years. The suggestion to narrow it down to a yes/no proposal in the discussion > phase is probably even better, though. > I agree with this, but so far there was no feedback which functions/methods people want to deprecate slower or faster, so I'm eager to hear about your and everyone else's opinion! Replying to Larry: 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. I don't think this "generosity" is really necessary, even though I appreciate your intention. For example, in case of ldap_connect(), the signature to be deprecated is not even documented at php.net... and it's only available on a very specific platform. I see no reason to keep this signature for 5+ years. The same goes for IntlGregorianCalendar::__construct() which seems to be a very underrepresented class as well. As I already said, most of the functionality to be removed is easy to replace, and it could be done via automation: i.e. you add Symfony Polyfill to your project and then Rector swaps the problematic function calls to the good ones. Sometimes not even tooling is needed, a simple search + replace is enough. With all that said, I think only a smaller subset of functions may deserve the longer depreciation period. Máté
