Re: Re: why bloated packages are bad (acaseforsplittingup large packages)

Hi Lukas Smith! On 08/15/05 21:28 you wrote: > Tobias Schlitt wrote: > >> Hi Lukas Smith! >> On 08/15/05 20:58 you wrote: >> >> >>>> There is a new tag provided (<compatible>) which has a large potential >>>> to solve this issue. Quoting from an email posted by Greg yesterday: >> >> >> >>> I got that one, but I just dont see what it solves. I mean will the >>> minor release then state its not compatible (untested) with PEAR? Then >>> you obviously cant upgrade to that version and therefore the entire >>> advantage of releasing that package update becomes moot. >> >> >> >> I think Greg stated the way it will work very clearly: >> >> - Package A depends on B. >> >> - B upgrades it's version. >> >> - User tries upgrade, which will throw a warning about maybe >> incompatible versions. >> >> - PEAR developers and experienced users can test if BC was broken with >> forcing PEAR to upgrade. >> >> - If all issues are fixed B releases another upgrade including >> <compatible>-tag OR package A updates stating it can work with new >> version of B. >> >> - PEAR will allow upgrade for users. >> >> Hope that explains the intensio of <compatible> better. > Ok .. > So it will take 2 releases for an update of a dependent package. > It will require a bunch of extra QA steps etc. > In the end it is clear that the QA'ing will have to be done on all of > PEAR either way. The only real difference is that only the version > number of the dependend package would have to be updated versus the > version number of PEAR having to be updated (as well as the number of > bytes that have to be transported, which I dont consider to be such a > large issue). Actually it allows us to state "PEAR will work with this version of a package" without implying "PEAR works with a newer version of this package", which I consider as a benefit. > I guess the question really is if the PEAR releases are really going to > be so infrequent that we in the end have to make releases just for the > bundled code. I just clicked through the last changelogs and I did not > find a single release we did just for adding features to the core > system. Usually the fixes, additions for the installer part drastically > outweight the changes to other components. If I get you right you say, that the installer only had to be released because of breaks in other packages? > And for this reason I am not convinced that we need to unbundle > PEAR_ErrorStack. I can't say anything on this topic, since PEAR_ErrorStack is Gregs thingy. For me it does make sense to unbundle it, when the maintainer conciders this necessary. Regards, Toby -- Tobias Schlitt - Zend Certified Engineer GPG Key: 0xA6529579 a passion for php http://www.schlitt.info Like to say "thank you"? - http://pear.php.net/wishlist.php/toby