At 11:21 18/5/2001, Jani Taskinen wrote:
As long as these extensions are in there, I think changing any of their
API's is a justification for 4.x release.
This is simply not the way we decided to work in. Can it be
changed? Sure. Should it be changed? In my humble opinion, no, it shouldn't.
On Fri, 18 May 2001, Zeev Suraski wrote:
At 11:21 18/5/2001, Jani Taskinen wrote:
As long as these extensions are in there, I think changing any of their
API's is a justification for 4.x release.
This is simply not the way we decided to work in. Can it be
changed? Sure. Should it be changed?
At 12:05 18/5/2001, Jani Taskinen wrote:
You must understand that I don't like changing the API either. But
sometimes it just HAS to be changed. And one thing that should
happen when such changes are made, is to change the version number.
Why is it so sacred to you?
Each and his own religion :)
On Thu, 17 May 2001, Rasmus Lerdorf wrote:
I don't agree. Have you noticed the thread about domxml currently running
in php-dev@? Wouldn't that justify a 4.1? What would?
No, I don't think a single extension should affect the PHP version number
to that extent. But I do think we should
On Fri, 18 May 2001, Rasmus Lerdorf wrote:
As long as these extensions are in there, I think changing any of their
API's is a justification for 4.x release.
I disagree. Since optional extensions are not a core part of the language
and can be built and maintained separately, changes to them
On Fri, 18 May 2001, Jani Taskinen wrote:
On Fri, 18 May 2001, Rasmus Lerdorf wrote:
As long as these extensions are in there, I think changing any of their
API's is a justification for 4.x release.
I disagree. Since optional extensions are not a core part of the language
and can be
On Fri, 18 May 2001, Rasmus Lerdorf wrote:
That still doesn't change the fact that it is imprecise to tie the PHP
version number to extensions when there is no 1:1 relationship here and
the possibility exists that an older version of the extension can be used
with a newer version of PHP.
And
On Fri, 18 May 2001, Jani Taskinen wrote:
Hmm..I'm not really sure how it's possible to use older API version
extensions with newer PHP as the Zend boys pump up their API version
number on every release..and afaik that prevents you from using the
old extensions..?
They hardly bump Zend API
That still doesn't change the fact that it is imprecise to tie the PHP
version number to extensions when there is no 1:1 relationship here and
the possibility exists that an older version of the extension can be used
with a newer version of PHP.
And more and more, the average PHP user does
On Fri, 18 May 2001, Rasmus Lerdorf wrote:
That still doesn't change the fact that it is imprecise to tie the PHP
version number to extensions when there is no 1:1 relationship here and
the possibility exists that an older version of the extension can be used
with a newer version of PHP.
Rasmus Lerdorf wrote:
[...] which increases the likelihood of old versions of extensions
sticking around and not being in synch with the PHP installation.
not to likely nowadays due to the API number changes that made
binary extensions not being loaded by other php versions then
the ones
Andrei Zmievski wrote:
They hardly bump Zend API version with every point release.
not with every release, somehow they missed 4.0.3 on this ;)
--
Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77
--
PHP Development Mailing List http://www.php.net/
To unsubscribe,
Ah. I must have been dreaming then.. :)
I remember that someone submitted some bug report about this very issue.
Anyway, now I see that there really is good reason having that
version (PHP_#ext#_API_NO ?) after all. And having that..we should
propable start moving those extensions one by
Andrei Zmievski wrote:
They hardly bump Zend API version with every point release.
not with every release, somehow they missed 4.0.3 on this ;)
No bump in 4.0.6 either, and it doesn't look like there will be one for
4.0.7 either. About 5 months since the last bump.
-Rasmus
--
PHP
Jani Taskinen wrote:
Anyway, now I see that there really is good reason having that
version (PHP_#ext#_API_NO ?) after all. And having that..we should
propable start moving those extensions one by one into PEAR?
do we have the infrastructure in PEAR for C code yet ?
Maybe we could then roll
Jani Taskinen wrote:
Anyway, now I see that there really is good reason having that
version (PHP_#ext#_API_NO ?) after all. And having that..we should
propable start moving those extensions one by one into PEAR?
do we have the infrastructure in PEAR for C code yet ?
Not yet, so this
On Fri, 18 May 2001, Rasmus Lerdorf wrote:
Ah. I must have been dreaming then.. :)
I remember that someone submitted some bug report about this very issue.
Anyway, now I see that there really is good reason having that
version (PHP_#ext#_API_NO ?) after all. And having that..we should
And btw. Why not have a function in PHP core that can be used to get the
desired extensions remotely from pear.php.net? If we have a
PHP_#ext#_API_NO, running a 'update_php_extensions()' would
go and grab the updated (if the extension HAS been updated) one..etc..
(I'm just thinking out
Rasmus Lerdorf wrote:
There will be more and more extensions that are not bundled with PHP, and
having a standard way to check the version of an extension is going to be
required. This should also apply to the bundled extensions.
Currently there is a number of self-description functions
in
[Jani Taskinen [EMAIL PROTECTED]]
On Thu, 17 May 2001, Rasmus Lerdorf wrote:
I don't agree. Have you noticed the thread about domxml currently running
in php-dev@? Wouldn't that justify a 4.1? What would?
No, I don't think a single extension should affect the PHP version number
to that
One thing I'd like to see is a utility which could check a source
directory and
warn about obviously deprecated / insecure / inefficient things. It'd make
life
easier for that hypothetical ISP admin with a large pile of code which has
been
haphazardly maintained for years.
hey, guys, how do
On Wed, 16 May 2001, Rasmus Lerdorf wrote:
Sure, but a version number if quite arbitrary and the way we have always
^^
Exactly..
done this is to consider the second digit for large changes. The fact
that we haven't had a .1
On 16 May 2001, Stig Sæther Bakken wrote:
Hey Jani, you can attribute yourself as the PHP Whipping Boy now if
you like. I think you just got enough points. :-)
Ok. :)
I completely agree that we should start using the minor version. It's
like we're afraid to touch it because that would imply
On Wed, 16 May 2001, Andrei Zmievski wrote:
Being antagonistically sarcastic won't win you any friends, Jani.
If I wanted friends, I'd get a dog.. :)
As far as your question about the version numbers, the middle digit gets
bumped up when we plan some changes that will break backwards
As far as your question about the version numbers, the middle digit gets
bumped up when we plan some changes that will break backwards
compatibility and implement features in the core language. So, yes, it
is something special, it's not for bug fixes or extension changes.
Exactly. As we now
Being antagonistically sarcastic won't win you any friends, Jani.
If I wanted friends, I'd get a dog.. :)
As far as your question about the version numbers, the middle digit gets
bumped up when we plan some changes that will break backwards
compatibility and implement features in the core
At 06:56 17.5. 2001 -0700, [EMAIL PROTECTED] wrote:
Being antagonistically sarcastic won't win you any friends, Jani.
If I wanted friends, I'd get a dog.. :)
As far as your question about the version numbers, the middle digit gets
bumped up when we plan some changes that will break
I really don't think that this should be something to strive for. There
should be a really really good reason for making changes that break
backward compatibility. We have that second version number reserved for
such BC breaking changes that don't involve a huge rewrite (which is what
the
At 01:40 15/5/2001, Sterling Hughes wrote:
Sure, yeah. But as a note, other big projects with huge user bases break
compatibility as well, Perl, Apache, Python, to name three.
It doesn't mean it's a good idea.
And in its own way, C, is constantly breaking compat, the amount of times
I've had
On Wed, 16 May 2001, Zeev Suraski wrote:
Also bare in mind that a very large percentage of the developers don't
*want* to be forced to change their code, and consider it to be a
Who's forcing anybody to update anyway?
misfeature in the language if it breaks downwards compatibility in between
On Wed, 16 May 2001, Jani Taskinen wrote:
Have you ever heard that you can also change that number in the middle?
4.0.6
This one^
It can be something else than an ellipse called zero..it can even be a
number 1!!! Whoa! Never thougth about that?!
And maybe, just MAYBE then
At 14:06 16/5/2001, Jani Taskinen wrote:
On Wed, 16 May 2001, Zeev Suraski wrote:
Also bare in mind that a very large percentage of the developers don't
*want* to be forced to change their code, and consider it to be a
Who's forcing anybody to update anyway?
We are, by not supporting old
Hi Andrei.
Yes, that's how it should be, but not how it is. At least I've been
observing PHP 4.0.x evolve dramatically with compat breakage included.
At 08:34 16.5. 2001 -0500, Andrei Zmievski wrote:
As far as your question about the version numbers, the middle digit gets
bumped up when we plan
new way:
call_user_func(array($obj, method), method, args, go, here);
---^
isn't 'pass by reference' deprecated too ?
harald.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Harald Radi wrote:
new way:
call_user_func(array($obj, method), method, args, go, here);
---^
isn't 'pass by reference' deprecated too ?
yes, so? the above is not pass by reference, your passing an array to
the function, not a reference to an array.
-sterling
--
At 01:06 PM 5/16/2001 +0200, Jani Taskinen wrote:
On Wed, 16 May 2001, Zeev Suraski wrote:
Also bare in mind that a very large percentage of the developers don't
*want* to be forced to change their code, and consider it to be a
Who's forcing anybody to update anyway?
misfeature in the
[Zeev Suraski [EMAIL PROTECTED]]
One comment; Why? :)
We've been in that discussion before. In my opinion, we should
probably rethink our whole deprecation approach.
Yes, I know that people don't like the burden of maintaining downwards
compatibility. I sure as hell don't. But PHP's
[Jani Taskinen [EMAIL PROTECTED]]
On Wed, 16 May 2001, Zeev Suraski wrote:
Also bare in mind that a very large percentage of the developers don't
*want* to be forced to change their code, and consider it to be a
Who's forcing anybody to update anyway?
misfeature in the language if it
-Original Message-
From: Andi Gutmans [mailto:[EMAIL PROTECTED]]
...
There has been lots of talk and I think there have also been
some good ideas.
The only problem I have had with these discussions up to now
is that people
here really forget that the average PHP coder is not a
At 08:31 PM 5/16/2001 -0400, Stig Sæther Bakken wrote:
[Jani Taskinen [EMAIL PROTECTED]]
On Wed, 16 May 2001, Zeev Suraski wrote:
Also bare in mind that a very large percentage of the developers don't
*want* to be forced to change their code, and consider it to be a
Who's forcing
At 10:27 PM 5/16/2001 -0400, Sean R. Bright wrote:
-Original Message-
From: Andi Gutmans [mailto:[EMAIL PROTECTED]]
...
There has been lots of talk and I think there have also been
some good ideas.
The only problem I have had with these discussions up to now
is that people
howdy,
Just sending a note about the deprecation of the call_user_method()
functions. It basically sends an E_NOTICE message now when
call_user_method() or call_user_method_array() are called. This is
because the call_user_method() and call_user_method_array() functions
can easily be
One comment; Why? :)
We've been in that discussion before. In my opinion, we should probably
rethink our whole deprecation approach.
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
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
On 14 May 2001 15:37:43 -0700, Sterling Hughes [EMAIL PROTECTED]
wrote:
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.
One thing I'd like to see is a utility which
45 matches
Mail list logo
