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

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). 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. And for this reason I am not convinced that we need to unbundle PEAR_ErrorStack. regards, Lukas