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.
Many don't. That is why it is important to iron out the API in alpha stage.
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).
Not at all, you can hit 2.0 as long as the API is the same. You can change it entirely as long as you provide the previous API (you can make it use the new one). Mark the previous API deprecated and you're set.
Think about shared hosts trying to maitain one system-wide pear install (and I know many have tried and gave up), if a new release means BC break you are making their life a nightmare.
Arnaud.