RE: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Naming changes.

Another option we should look at is having the following in configure --compat-mode /* depreciated functions issue notices */ --strict-mode /* depreciated functions dont work at all */ then when developing new stuff (ie on dev servers) people should use strict-mode but on production servers --compat-mode should be used (especially by ISP's and the like) James > -----Original Message----- > From: Richard Lynch [mailto:richard@zend.com] > Sent: 28 December 2000 17:45 > To: PHP Quality Assurance Team Mailing List; PHP Developers Mailing List > Cc: Zeev Suraski; James Moore; Sterling Hughes > Subject: Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Naming changes. > > > > Actually, I think that shattering compatibility like this should be a > minor > > IMHO: > > If the functions that used to work are issuing Warnings in the first phase > of change, I'd also say that's worth a 4.1 Otherwise, web-sites using > error_reporting=15 will break all over the place on a minor revision, and > that's bad... Actually, even with a 4.1 that would be bad... > > If the DOCUMENTATION is changing first, along with both function names > silently "working", and then in a *later* revision the Warnings start > appearing, followed by escalating error signals (as outlined by James, I > think) minor revisions would be okay... > But it would probably be good to not escalate every minor revision -- More > like 2 or 3 minor revisions per escalation to give people time to > adjust not > only their code, but to the "plan" > > Perhaps all renamed functions should have an auto-generated link to a web > page explaining the procedure, whatever it is decided to be, and > the list of > planned name changes with a time-table or revision schedule... If that > could be worked into the macro[s], it would probably help a lot. > > I guess I'm suggesting the following "phases" for James' plan: > > Phase I > 1. Documentation notes both function names, clearly marking the > deprecated one, with a link to a page describing the scheduled changes and > list of functions to change. > 2. Both functions work with no warning/error/etc > > Phase II, at least 2 or 3 minor revisions later > 1. Documentation notes both function names, clearly marking the > deprecated one with a note about the warning message, and the same link as > above. > 2. Deprecated function issues the lowest level Warning possible. > > Phase III and following, at least 2 or 3 minor revisions after previous > Phase > Same as above, but one level higher in the error system. > > Final Phase -- The deprecated function should remain in the > manual another 2 > or 3 revisions, and finally be phased out. > The *new* function names should continue to point to the page > describing the > changes that occurred and list of functions that changed at least through > and including the next *major* revision. >