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

Lukas Smith wrote: > Tobias Schlitt 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. No, this is not how it would work. The absence of <compatible> implies that a package has not been fully tested or approved. It doesn't prevent upgrade, it just prevents casual upgrade to a potentially dangerous situation, something that PEAR 1.3.x does not provide, and the primary reason that dependencies have been dangerous in mission-critical situations up to now. All it would involve is this checklist upon releasing a package like PEAR_ErrorStack or Archive_Tar: 1) has it been tested with PEAR by me, and by the PEAR devs and given the green light for release? -> no |--> option #1 wait until there is feedback, and then release with <compatible> (best option, imo) |--> option #2 if there is great demand for the release (security fix, for instance) release *without* the <compatible> tag, allowing for anxious devs to test and upgrade using --force, when the PEAR package devs finally provide feedback, an identical point release of the dependency package can be made with the <compatible> tag, or the PEAR package can have a point release with an upgraded <recommended> version -> yes |--> option #1 release with <compatible> tag |--> option #2 release without, and expect PEAR to do a point release with an upgraded <recommended> version Note that it is extra work to add the <compatible> tag, but this is the point: it suddenly becomes difficult to release a borked PEAR dependency. Sudden releases like Console_Getopt's accidental destruction of the CLI installer simply can't disrupt the installer unless the developer explicitly adds <compatible> in an irresponsible manner. It doesn't make it impossible, but it does make it much harder to do this as <compatible> requires explicit version numbers to function. The best thing is that users do not lose the chance to upgrade, it simply prevents accidental breakage of dependencies. I should start another thread for this, but there are a couple of other conditions that should be met in order to be a dependency of the PEAR installer (PEAR leads must be leads in the dep packages so that releases can be pulled on a moment's notice, for instance) that will help to guarantee the ultimate stability of the PEAR installer package. Greg