Yes, but this policy was put in place to save the users. If they
upgrade to a new version of a package with BC breaks then their
scripts will stop working. Remember that PEAR is sometimes installed
by people who are simply getting dependencies to another package. They
could easily, unwittingly, install a version which is incompatible.
This is (part of) why BC rules exist.
Maybe I'm the only one that reads the CHANGELOG before updating? Also, as long as the package that depends on the BC broken package has been updated there shouldn't be any problems upgrading (as long as the depended upon package isn't used elsewhere).
I guess I just don't see a huge need to "save the users" when these people would have had ample knowledge ahead of time, a CHANGELOG, etc. I'm not talking about rolling out a 2.0.0 release without first making it 2.0.0 alpha -> 2.0.1 beta -> 2.0.2 stable. They'd have plenty of time to fix their code.
The Linux kernel is an etirely different beast. First of all you have
to know (somewhat) what you're doing to upgrade to a new one. It's not
as simple as "pear upgrade-all". Second, the kernel's API doesn't
really change. At least not the exposed API. The internal API can
change in all sorts of ways and it won't affect programs which run on
top of it. If an external change is made a huge deal is made out of
it.
Have you used make-kpkg under Debian? Also, you're basically saying that since PEAR users are too stupid to understand that sometimes API's change with major point releases that we have to insulate them with Foo_Bar, Foo_Bar2, Foo_Bar3, Foo_Bar4, etc. Not to mention things get really hairy when you have packages A and B relying on Foo_Bar, while packages B and C rely on Foo_Bar2 and then package D relies on Foo_Bar4. I now have 3 different Foo_Bar packages installed, each with slightly (not drastically) different API's.
I've also heard that it's OK to break BC, change the API, deprecate,
etc. as long as it's a major point release (ie. 1.0.0 -> 2.0.0). This
makes *much* more sense, IMO.
Yes, this is true. However you're missing that switching to a new
major revision also means that you release a new package with the new
version # on the end.
Are you kidding me? So when Payment_Process hits 2.0 I have to roll out Payment_Process2 and then when it hits 3.0 I have to roll out Payment_Process3? So what happens when 5 years from now I'm on version 5.0? Am I supposed to be supporting this package indefinitely? And, if not, then can I move Payment_Process5 back to Payment_Process (as it's not being actively developed or supported I should be able to totally break it).
--Joe