Re: bundles

Stig S. Bakken wrote:

There are significant bugfixes in PEAR_ErrorStack that need to be released, but I can't just release the entire PEAR package because 1/5 of it has changed. Console_Getopt can never be changed because it will instantly break all PEAR installations (and it did a few months ago). System is a component that could easily be a separate package.

IMHO, this is about build/release management, and should be dealt with before packaging. In my experience, the best solution to this, bundles or not, is to have a stable (CVS) branch for each PEAR major.minor release, ala http://pear.php.net/manual/en/standards.cvs.php (that page is actually a bit misleading, since it calls branches QA_n_n_n, while QA_n_n is really what you want according to current CS).

I really don't see any way this solves the problem, there already is a branch for PEAR_1_3, which is stable, and HEAD is unstable. This has no effect on the problem at all.

The PEAR package is a bit special actually, and if I did this today I would embed Console_Getopt and System differently, and not have any package dependencies in the PEAR package.

The flaw is in the way dependencies are designed - there is no way to specify a range of acceptable versions and a set of specifically certified versions. This idea, by the way, is hardly new. Windows installer has supported the idea for years. It is possible to download dependency bundles and upgrade them independent of the primary application (.dlls, for instance). Specific versioning is used, and it has worked brilliantly. It's much better than the old days when you were forced to download the whole thing over again.

2) Different chunks of a large package have different stabilities. Right now, PEAR is stable, but PEAR_ErrorStack is alpha. This is inherently confusing to users.

Yes, it is. But having an alpha package bundled with a stable bundle/package is no less confusing! The package manager isn't the right place to deal with this sort of problem.

I don't understand. Are you saying that we should never be allowed to add new, complex features to stable releases, even if they don't affect existing functionality? (probably not - but bear with me as I try to understand :)

3) People often want only a sub-section of a package, such as File_VFS, which is stuck forever as a subpackage of File, and can never be extracted because of BC issues. With the bundling solution I've described, it will be possible to extract File_VFS, finally, into its own package, while maintaining BC with the existing File package.

But is this is general problem, or a specific one caused by some bad decisions done for the File/File_VFS packages, or some other "historic reason"? Would PEAR developers repeat the same mistake again now that we've learnt these things the hard way? I'd prefer that we all learn from these issues, fix the specific problems for those specific packages, and just make sure it doesn't happen again.

This is a general problem. Developers continue to make mistakes no matter how much we learn from the past. When you design an application, you don't necessarily know the best way to use it. What was once an ancillary part of the package may become crucial to more people than the primary part.

4) Once a package is split up, it's very difficult to coordinate the pieces, especially at uninstall time.

But you have that problem regardless, as long as it is possible to upgrade part of a bundle separately. It simply has to be dealt with either way.

The only solution is to be more strict with versioning in a dependency. Each dependency should specify a recommended version that will be installed _regardless of available versions_. On the other hand, a newer version of the dependency should be able to specify _explicit_ compatibility with the older versions. Anything else would error out and cause installation to fail, except for the use of --force (or a new option specifically for this, --relaxedversioning), which would allow installation the way it works now. Since I will be the one writing the code for this, perhaps it's best to let me write it, and we can always remove it after there has been some regression testing. Regression testing always finds the bad ideas. The point is, I am positive that these problems exist, and can be elegantly solved in a way that supports both the upgrade freak and the fear-of-breakage users, without requiring any advanced knowledge from the fear-of-breakage folks, or pain from upgrade freaks. I've already willingly removed entire files that didn't make sense after the initial design, so this would be no different.

You probably missed the message (or maybe you didn't and hated it :) where I described the solution I think will work best, it's at: http://news.php.net/php.pear.dev/33393

I may or may not have ready it :) news.php.net times out here though, but if you give me the subject+date I can find it in my own archive.

subject: possible solution to bundles vs. bundles [sleeping does help!] date: Wed Sep 15 17:36:32 2004 Greg