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 :)
More seriously, yes, I realize that sometimes the API *HAS* to be
changed. Those cases are relatively rare, and should remain as such. In
cases where the main reason for 'HAVING to change' the API is code bloat
(e.g. the mysql_db_query() function), I'd argue that keeping it makes much
more sense, with or without version changes.
>I didn't suggest either that if the version number is changed it's okay to
>break BC..
>
>There are now _two_ extensions that break BC. (sockets/domxml)
>So is it okay to break BC in extensions? And like that one user said,
>if we had pumped up the minor number he would have expected to see some
>major changes. But as long as you continue this 'this is how we have
>always done things' way, people WILL get pissed. Not only me.
Could be. To be honest, I'm not sure what the best solution would be
here. Coming out with an API that later changes is simply a bad thing, but
it's all too common in PHP. IMO the problem is with the initial design,
i.e., we should perhaps invest more time in designing the API to begin
with, instead of just coming out with something, and later improving on it
(sometimes by changing it completely).
I don't mind using the middle version number to signify major changes in
the API. Judging by other projects, though, people would probably expect
substantial functionality improvement from such version changes, while in
practice, they'd be the same.
Zeev
--
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]
