Re: Latest commit -- depreciation of call_user_method()

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