Re: bundles

Okay, go ahead, implement it and prove me wrong (I agree completely about version ranges btw). - Stig On Mon, 2004-09-20 at 18:04, Greg Beaver wrote: > 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