Re: Re: Naming changes.

From: Date: Thu, 28 Dec 2000 19:48:05 +0000
Subject: Re: Re: Naming changes.
References: 1 2 3  Groups: php.dev php.qa 
Request: Send a blank email to php-dev+get-42470@lists.php.net to get a copy of this message
At 20:51 28/12/2000, Ron Chmara wrote:
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.
I don't agree. There are examples that go both ways, and as far as this is concerned, I prefer going after the Linux model. Linux bumps a major version number only for nearly-complete rewrites or huge fundamental changes. Minor (2nd digit) numbers denote significant changes that could affect functionality, but generally the whole thing is more or less ok. 3rd digits denote small fixes, minor additions (new drivers) etc. I think this model makes sense. I consider PHP 4.0 to be a platform. As long as things are more or less the same, it's the same PHP 4.0 platform. If we start bumping major version numbers every time something changes and could affect deployment, we'll find ourselves in version 20 quite soon. You may argue that this is meaningless, but it pretty much isn't, because nobody (well, almost nobody) does that, and a high version would look very odd and would appear as if it took us way too much time to 'get things right'. Linux is in version 2.0. Windows is in version 5.0. Perl is in version 5.6. About the issue at hand, I'm not too sure about it. I tend to think that old function names should be phased out *very* slowly. I know that this is an issue that is very annoying, and we want to nuke the stale function names ASAP, but fact is, it's not really all that important. We can mark all of these functions as was proposed, and have an INI option that would warn people when/if they use them, or even deny their use completely. When the time comes to change the version (for reasons other than this, as I mentioned above) - we can remove them. The stale function names shouldn't rush us to release new versions. If we release version 5.0 or even 4.1, with the main change being a set of functions that no longer work, don't expect a hysterical success :) Zeev -- Zeev Suraski <zeev@zend.com> CTO & co-founder, Zend Technologies Ltd. http://www.zend.com/

« previous php.dev (#42470) next »