The current way of using the version numbers is really stupid.
Of course people expect that there aren't anything else but
some minor changes / bug fixes if we constantly pump up only the
micro number.
Wouldn't the following make more sense:
PHP 4.0.x -> bug fixes, minor changes, very few new functionalities
PHP 4.x.0 -> many new functionalities, breaking back.comp., etc.
PHP x.0.0 -> rewrite of all this shit
This way we could finally move forward and stop this endless discussion
of breaking the back.comp..
Speaking of back.comp., wtf does the Zend engine break back.comp.
in micro releases? ie. those kind of changes in core that REALLY
break back.comp. should cause at least a minor version number pump up.
Or is there some other reason in behind that? Like why is it necessary
to always get a new Zend optimizer for each release?
Also the separation of PEAR into it's own will never succeed if this
keeps on happening (the C modules in it). Only makes people to want
their extensions to be included in the PHP cvs.
--Jani
On Mon, 14 May 2001, Sterling Hughes wrote:
>Zeev Suraski wrote:
>
>> One comment; Why? :)
>>
>
>
>Simple, there is no point in having two functions which can do the same
>things. call_user_method was the less flexible of the two, so I
>
>
>> We've been in that discussion before. In my opinion, we should probably
>> rethink our whole deprecation approach.
>
>
>Yep, we need to decide on a standard for deprecating things.
>
>
>> Yes, I know that people don't like the burden of maintaining downwards
>> compatibility. I sure as hell don't. But PHP's huge popularity boost
>> put the development team in a position where it has *a lot* of
>> responsibility; Doing the wrong thing will reflect badly on PHP and its
>> acceptance as a stable solution (not segfault wise, but development wise).
>>
>
>
>Sure, yeah. But as a note, other big projects with huge user bases
>break compatibility as well, Perl, Apache, Python, to name three.
>
>And in its own way, C, is constantly breaking compat, the amount of
>times I've had to upgrade programs i've written, because a library
>changes is countless...
>
>
>> On the other hand, I really don't like the bloat either.
>>
>> So, what should be done? In my opinion, the approach of adding E_NOTICE
>> notifications to functions doesn't cut it; It won't significantly
>> improve the situation. I think we should go in a different path (or an
>> 'extended' path) - IMHO, the best approach would be adding some sort of
>> a 'LEAN_AND_MEAN' mode to PHP's build. When built in this mode, bloat
>> code will be #define'd away, or displayed as 'deprecated' in a similar
>> manner to the way warn_not_available works. That gives everyone almost
>> everything - people who care about the bloat (like me) will build it in
>> LEAN_AND_MEAN mode, hosting companies or legacy sites, who care most
>> about having their code go on working with minimum hassle - won't mind
>> the added bloat. If kept closely documented, people who care enough
>> about the bloat will be able to go through the checklist, make sure
>> their sites are compatible with it, and turn this mode on.
>>
>
>
>well, you can't have your cake and eat it too.
>
>(did I say this before when talking about backwards compat,
>AHHHHHHHHHHHHHH, hey Zeev, is PHP an OO language? ;)
>
>Well, what I intended to do was mark it with an E_NOTICE for this
>release and if no one complained with my latest commit, redo the
>call_user_method*() documentation as well as a big ass news entry.
>
>Next release, bump up the level to E_WARNING, and add a nice sized NEWS
>entry about that.
>
>Finally, third release, say buh-bye to good old call_user_method, and
>replace it with a new function, warn_depreciated.
>
>However, you have a very good point, ISP's will be pissed if we
>drastically change the syntax. And your solution seems good, I'd just
>do the reverse (semantically speaking), so instead, what I think we
>should do is have a --enable-backwards-compat mode. This mode would be
>for ISP's and people who need the bug fixes, etc. in new PHP releases,
>but don't want to upgrade their scripts.
>
>So, when deprecating a feature, the following is employed:
>
>minor release 1: non backwards compat mode
> php_error(E_WARNING, "DEPRECATED FEATURE BUM!");
>
>minor release 2:
> now the function warn_deprecated replaces the deprecated function in
>non backwards compat mode, backwards compat mode is the only place the
>function is no longer present. The function code is moved to php4/legacy.
>
>
>> The only drawback I see to this approach is that the code itself remains
>> and 'bloats' the various files. We can probably overcome this problem
>> by separating legacy code to separate files.
>>
>
>
>or a seperate directory, backwards compat code can be placed in php4/legacy.
>
>
>-Sterling
>
>
>
>
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
