Hello, chiming in: >> > So what solution is there to this? Should it not be deprecated? This >> > same issue (is still happening) with register_globals for us, but it's >> > acceptable as it has been phased out. Should there be no deprecation >> > warning now and wait for a future release? >> >> I'd like to see usage drop off first so we aren't negatively affecting >> millions of sites performance-wise, and/or we streamline the error >> handling code so there is a way to avoid this performance hit.
You are never going to see usage drop off until it is announced unequivocally that the feature is going away on X release. Furthermore, all that can be done is to perform due diligence in giving those who still depend on the feature proper affirmative warning. In the end there are going to be people who a) refuse to believe, b) didn't know (ultimately their fault) c) didn't care (again, their fault) or d) were completely powerless to do anything about changing their system (an edge case at best). The feature can be marked as unsupported (officially) in the announcement and moved to a pear module without ever actually depreciating it. Anyone whose life depends on it is free to continue using it (hosting providers will most likely continue bundling it). Anyone who is interested in maintaining it is free to do so. If the module goes X amount of time without any maintenance/development (say, PHP 6.1 should be plenty of time) then it can officially be depreciated with all the warnings and fanfare we're talking about. The problem is in getting announcements to the people who depend on a module. The people most likely to be in the blinders for PHP feature changes are those of ISP/hosting customers, and most hosts do a pretty good job of alerting their customers to prominent changes to their server configurations. Beyond that, there's nothing else we can do for the people who do nothing but to do nothing ourselves. I don't think that is legitimate stratagem for PHP internals. >This makes sense, but from an engineering standpoint, what can be used as >a >trigger to move to a more recent driver outside of deprecation? I'm not >sure there is another solution. > >Your argument is valid. The question of, why do we deprecate something >that is so heavily used comes to mind, but in the end, this is a something >the extension maintainers want - not end users. Maybe the correct >solution >is to hand off the maintenance of this extension to a new team? I'm sure there are people who are still relying on some software package that only works on Windows 3.1 where both a) Microsoft and b) the original software developers are no longer supporting the software or platform. The reason to depreciate and/or cease support for a feature (not the same thing) is for the sake of prioritizing time and resources on the forward momentum of PHP and not being obligated to support and maintain antiquated technology, regardless if it is still working or not. I think it is safe--and better--to accommodate typical users' case rather than hinging on behavioral edge cases. -Austen
