Re: The point (BC breakage)

Hi back at you ;) Alexey Borzov wrote:

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? ;]

Doesn't it order a pizza?

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.

Of course it can - my point was that since it can't now, nobody uses it that way, and we can't rely upon installations using that setup. Similarly, PHP 5 could be written to have namespaces, but the fact is that it doesn't right now, so it wouldn't make much sense to plan on them in PEAR for PHP 5.

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?

This could be a problem, I'm not sure what you'd like to see differently in the RFC, however, as major version upgrades could simply remove all the deprecated junk, which seems to be separate from the issues the RFC addresses?

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.

This is actually a great example - a few webservers are still configured to run both PHP 3 and PHP 4 depending on the file extension. The same will be true when PHP 5 comes out (PHP 4 and PHP 5 can co-exist). The RFC adds this ability to allow different API versions to co-exist in PEAR.

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?

I think it should be clear that if Foo version 2.0 is available as Foo_v2 2.0, pear upgrade Foo will simply fail with "most current version is installed, use pear install Foo_v2 to install Foo version 2.0" - no confusion, the user could only think the upgrade was successful if they didn't read the message. As for reasons to add the level of usefulness, I can think of many reasons why the current state of the installer isn't solid, and would be happy to repeat them if the previous posts regarding these problems don't make sense.

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?

API versions can't co-exist without it, no?

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

However, well-designed packages will be rapidly adopted. The speed of release means more if the quality is there to back it up. This is all abstract anyways :). Packages will have the quality an author puts into them regardless of their name.

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.

Right - but most small-time end-users won't be running MDB and MDB_v2 alongside each other, and they can use a wrapper - similar to the DB and metabase wrappers already included with MDB - in order to convert MDB_v2 into MDB. Obviously applications designed to use packages that use MDB will not need to worry about the MDB code. I only wished to illustrate that the biggest annoyance of the RFC for these users can be solved pretty quickly, but doesn't limit power users either. Greg