Re: [PHP-DEV] Re: [PHP-QA] Naming changes. From: Zeev Suraski (zeev <email protected>)
Date: 12/28/00

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 <email protected>>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: php-dev-unsubscribe <email protected>
For additional commands, e-mail: php-dev-help <email protected>
To contact the list administrators, e-mail: php-list-admin <email protected>