Re: package validation (was Re: PHP_Beautifier-0.0.6.1)

From: Date: Sun, 06 Jun 2004 19:53:30 +0000
Subject: Re: package validation (was Re: PHP_Beautifier-0.0.6.1)
References: 1 2 3  Groups: php.pear.qa 
Request: Send a blank email to pear-qa+get-1398@lists.php.net to get a copy of this message
Greg Beaver wrote:
Stefan Neufeind wrote:
Same here. I wonder if additional checks might be useful that you can't do with a regex - e.g. testing for versionnumber and state- combination (linux-kernel-style where an odd number would demand beta- state) or so. Maybe a combination - so we allow for additional checks but make lightweight checks available by a regex.
I've put some thought into why I think this is such a bad idea, and here is my reasoning. Once code is installed on the user hard drive, it should be considered essentially permanent. In other words, if a channel decides to switch the version validation scheme, the user has to download a whole slew of classes under the system proposed by Tomas. If 5 channels or 10 channels do this, we could be talking a half hour of downloads just to get the validation code. With the implementation I've set up, it will take about 45 seconds to download, even with ultra-slow bandwidth. The more download requirements placed on a user, the less likely that PEAR's channel feature will be useful or popular.
My idea was to create a package, handled by the QA team. This package could be named ChannelValidation_<channel> and could for example be specified in channel.xml. In most cases this will be just one gzip'ed file :-) I don't "mind" if it should be done extending a class or not, i'm just worried on how to get validations out of the core and how to provide a way for each QA team a way for handling that out of PEAR package maintainers.
In addition, pre-existing releases using the old version numbering scheme would suddenly become invalid.
Nah, that's why we have the release date for verifiying that, would even support rules changing over the time :-) Tomas V.V.Cox

« previous php.pear.qa (#1398) next »