Re: The point (BC breakage)

Hi! Greg Beaver wrote:

Which is more complicated?

...

User, curious about version 2.x, reads up on the package page, decides to install the package, update the app and after some time, migrates the application to package Foo_v2.

This (auto-upgrading to minor releases only) can be done with current PEAR installer, without introducing another layer of complexity. You do know *what* the installer does now on 'PEAR upgrade PHPUnit', when stable PHPUnit is installed, don't you? ;]

This does not reflect reality. Nobody in the world has a central install of only the core, and user installs of user files. The pear command won't even RUN as non-root. This is a totally bogus suggestion.

Can't pear command be fixed to run as non-root without this RFC? Thought so.

Alexey says: 1) The proposed handling for mostly-compatible major versions and complete API changes is the same: this adds to confusion. Greg's answer: the whole point is that "mostly compatible" versions imply poor design on the programmer's part, no? The API should not reach 1.0 until it is stable. If that API needs to be changed it is a big deal no matter how small the change is.

What about major feature additions that leave lots of deprecated stuff lying around?

Alexey says: 2) The BIGGEST problem: after upgrading to a new major version of the package I'll have to edit my application even if it is *completely* compatible. This can lead to: Greg's answer: Why in God's name would anyone release a new major version if it's practically the same as before? This is currently possible in PEAR. Please name ANY other major software project that has done this. Apache? PHP? Mysql? Perl? There are no examples. The API is only changed when it is clear that there are no workarounds, and it is changed to make things significantly better after careful consideration, never lightly.

Major version bumps in overwhelming majority of projects mean not 'huge BC breakage', but 'major improvements'. Think PHP3 -> PHP4. As for 'currently possible in PEAR', that's why we need a good versioning scheme, not a way to push half-baked stuff to different dirs.

Alexey says: 2a) Confusion: release notes state that Foo version 3.0 has major performance improvements, why don't I notice anything after upgading to it?.. Greg's answer: This confusion is easily remedied by the same technique used to read about packages in the first place - RTFM. The package page will explicitly list the packages, and upon running pear upgrade XXXX the installer will list API upgrades as well.

This wonderful technique works now as well. PEAR installer can be fixed to show different upgrade scenarious without adding a level of complexity. Why add this level?

Alexey says: 2b) Bit rot: now authors of dependent packages should at least follow the development of their dependencies. Wonderful things can happen when they know that they can always rely on an old and buggy version... Greg's answer: This makes zero sense. Package authors can now depend on the API of their dependencies not changing. Any package author who wants his or her package to be used will clearly want to upgrade to the new major version if it is better, and that is not any harder to do with the current system - still, every usage of the dependency has to be checked for BC breakage. I highly disagree with designing PEAR for lazy-asses who don't want to write good code :).

Depending on the API can be done now by depending on version range *and* enforcing the versioning scheme (see above). Why add a level of complexity?

Greg's main point: How often should an API change? RARELY. When it does change, it should be a BIG DEAL(tm). If the API needs to change regularly, this is simply a sign of crappy programming to begin with. Rapid development can and should happen (this includes rapid API change) in alpha and beta releases preceding a new major version number. This is the whole point of alpha and beta. Stable means stable - it doesn't change much, and does what it is advertised to do. Users and developers have to be able to depend on this, or most of them won't use the package.

API may change because of a major feature addition. Having the proposed stuff in PEAR will prevent rapid adoption of "rapidly developed packages".

PEAR already requires users and developers to do all kinds of things like learn how to program in PHP, learn how to set their include_path and how it works. Here is the maximum confusion I can see: User: How do I use MDB 2.0? List: pear install MDB_v2 User: Do I have to change all my code? List: No, but you will have to change some of it. Use this code as part of your application and you won't need to change the classname class MDB extends MDB_v2{}

You *do* understand that this user will lose the ability of running MDB and MDB_v2 alongside each other after doing this??? And this is the main selling point of your RFC.