Re: [PHP-DEV] Re: [PHP-QA] Naming changes. From: Ron Chmara (ron <email protected>)
Date: 12/28/00

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 <email protected>, 520-326-6109, http://www.opus1.com/ron/
Work: rchmara <email protected>, 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.

-- 
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>