> >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 language. So, yes, it
> >is something special, it's not for bug fixes or extension changes.
>
> Exactly. As we now agree with it, let's get busy and start breaking
> things! :)
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 first version number is for). And yes, we have been very afraid to
make such changes, as we should be! And the fact that we have never had a
.1 is an indication of just how unwilling we have been to make such
changes. I see this as a success and not as a failure. Imagine writing a
PHP package and having to indicate that this package will work on PHP
4.0.x, not 4.1.x and 4.2.x, but 4.3.x is fine.
But, if a good case can be made for such changes, or if we have a large
set of feature changes, then sure, let's use that second version number.
It isn't a rule written instone that the second version number is
exclusively for BC-breaking changes. That's just what we have done so
far.
-Rasmus
--
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]
