Re: Re: Naming changes.

Sterling Hughes wrote: > > Is there any special reason so many people want to move to 4.1 just like > > that? :) A miniversion is fine for this type of change. We're fine at 4.0. > > So far, changes in the major version number were due to serious > > architecture changes. Changes in the minor version number were planned > > (for 3.1) but never actually executed, and they also involved architecture > > changes, but not major ones. Mostly everything else falls in the > > miniversion (3rd digit) category, we'll have dozens of those in the future. > What can I say, 4.1 just sounds cooler... ;-) > Actually, I think that shattering compatibility like this should be a minor > version number (at least, perhaps even a major version number, hey, everybody, > gear up for PHP 5.0 :). IMNSHO: Any times there are major compatibility changes, UI changes, or interface changes, it's time to add a major version number. Of course, we try to minimize the impact, but a major number indicates to users that it's something that _must_ be tested before deployment. Minor version numbers and miniversions are usually "under the hood/bonnet" changes. Whether or not breaking functions is "major" or "minor"... I'd say it depended on the php user base actively using the function. YP/NIS function names being changed are not as major (in terms of users) as MySQL function names. This just provoked an additional idea for managing obsolescence of function names... add a php.ini directive: obsolete_warnings=on|off [on=default] With the deprecated function name/alias/usage invoking a warning macro, one (major/minor/mini) version prior. This would allow us to use a generic "this function name is planned for obsolescene" Warning (not notice) in a prior version, before phasing it out in a future one, and yet would also allow users to upgrade for bug fixes and make their changes gradually, after the initial shock. It'll still be painful for users, but it will give them a current code base to run with, a visible reminder, and can easily be turned off while they fix their code. ISP's/hosting sites are another issue, where this idea may still need more thought. -Ronabop -- Personal: ron@opus1.com, 520-326-6109, http://www.opus1.com/ron/ Work: rchmara@pnsinc.com, 520-546-8993, http://www.pnsinc.com/ The opinions expressed in this email are not neccesarrily those of myself, my employers, or any of the other little voices in my head.