Re: package validation (was Re: PHP_Beautifier-0.0.6.1)
| From: | Tomas V.V.Cox | 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: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.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.
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