Re: PEAR 1.3b3 problems

Just a nitpick at the top, it is "deprecated" not "depreciated", the second is used in economical/financial contexts when the value of something is decreased with respect to some standard. Whereas "deprecated" is used when something has been replaced or superseded by a something newer. --- Alan Knowles <alan@akbkhome.com> wrote: > Greg Beaver wrote: > > Hi, > > > > I just committed fixes for the bugs in the installer for PEAR 1.3b3 - > > please try out the changes if you get a chance. checkout php-src/PEAR, > > and after backing up your PEAR directory (a zip file will be enough), > > pear upgrade php-src/PEAR/package-PEAR.xml. If things work fine, simply > > do a pear install --force PEAR to revert. > > > > I would like to see 1.3 get out the door, as there are several crucial > > features waiting to be introduced for 1.4, such as the new BC stuff, > > subpackages, PECL things, and the new revert command. Yup, subpackages and revert will be a good thing. > > One major technical issue not addressed by the new BC RFC also needs to > > be worked out, which is how the installer will automatically identify a > > new major version. I think simply adding in a package.xml attribute > > will be enough. > > > > > > > <package> > > <name root="DB">DB2</name> > > > <depreciates>DB</depreciates> > or > <replaces>DB</replaces> We could use "deprecates", "replaces", or "supersedes" all will have the same connotation. > seemed like the obvious choice... > > obviously the trickery on pearweb is a bit nasty > > Thinking out loud.. > > a) flag packages as depreciated, with the name of the new package. > b) have a new package record for the new replacement. > c) store the old package name in an extra field in the package description. > d) ignore depreciated from the browse pages Ack. We have to envision that not only single packages will supersede older versions, it might happen that two packages could gravitate to each other and end up merged into a new one that replaces the two older ones, etc. > > e) on DB2's page just show a link saying > Used to be called _DB_ (with a link to that package page..) Yep, +1 on this, it can be more than one link (see prev comment) > > f) on DB's page show a bit warning (as it's flagged depreciated) and > what it's depreciated by. > > g) on search results indicate that something is depreciated.. > Perhaps allow in an "Advanced search" to include/exclude deprecated packages. Should there be a link from the deprecated package to the new one too? > While it doesnt quite follow the line of keeping one 'package page', for > a major new version. - I think that the implementaiton of this may be a > little problematic.. (and as long as it's clear that there is a > connection between the two, I dont think it's going to throw people too > much..) > > As far as downloading.. - It may add a little complexity.. - as the > download of the old package tgz file should expect a warning (eg. this > is depreciated) + try again??? with ?warning_issued=yes... > > Regards > Alan > > > > > > > > > Otherwise the ambiguity is a bit too dangerous to handle automagically. > > > > I don't really like "root" as the name, perhaps firstversion or > > something clearer? > > > > go-pear NEEDS fixing!! There are only a few people with pearweb karma. > > I'd like to suggest that anyone with the free time should request > > temporary karma in which to develop the go-pear and fix the outstanding > > bugs. > > > > Regards, > > Greg > > Cheers ===== -- Jesus M. Castagnetto (jcastagnetto@yahoo.com) Research: http://metallo.scripps.edu/ Personal: http://www.castagnetto.org/ PEAR stuff: http://pear.php.net/user/jmcastagnetto __________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree