On Wed, Sep 3, 2008 at 4:56 PM, David Cantrell <[EMAIL PROTECTED]> wrote: > On Wed, Sep 03, 2008 at 03:00:40PM +0300, Gabor Szabo wrote: > > >> I'd like to see people also test modules that were uploaded long time ago. >> (the latest version of them) and not only the recent uploads. > > I did this some time ago and have tested everything uploaded since > (except those that I've deliberately excluded from testing for various > reasons). It annoyed a fair number of people, partly because my > algorithm for figuring out what's the most recent was a bit stupid and > so if a module changed maintainer it tested both USERFOO/Some-Module-1.0 > and USERBAR/Some-Module-3.7. Also, while I was doing this on several > platforms, I stopped them all as soon as one reached the end. Mostly > because it was taking a lot of my time.
IMHO if you make sure not to send any report to the author on old versions of the modules they won't be annoyed. They will probably not see at all but those who need to find an older but functioning version of the module will be helped. > I believe that brian d foy has recently been doing some backpan > archaeology, so it might be worth someone else doing this at some point > once he's written some nice tools. yes, that might further improve the situation for the archeologist. > >> If you want to give a service to those who don't want to >> upgrade then try to figure out what is the newest version of a module >> that still works on your platform os. > > These go some way towards that: > > http://bbbike.radzeit.de/~slaven/cpantestersmatrix.cgi?dist=CGI-Upload%201.11;maxver=1 > http://bbbike.radzeit.de/~slaven/cpantestersmatrix.cgi?dist=CGI-Upload%201.11 > > which is linked as "Perl/Platform Version Matrix" from search.cpan.org. Now you are stepping on my open wounds. I wrote such a matrix almost two yeas ago integrated to the CPANTESTERS interface but it was never loaded to the real site. Now it is partially included http://www.cpantesters.org/stats/ but I think it is not being generated. The cross reference table actually was showing the latest version of a module with a passing report for the platform/perl version matrix. It is quite sad and I hope Barbie will have the time to integrate it. Anyway there is another way of testing I'd like to see. The use case is when DBD::SQLite had a new version (a minor one, not the SQLite2->3 switch) which worked well on its own but one of the modules that was depending on it (I don't remember which one) that was released earlier stopped working. I'd like to see some of the processing power turned into finding such issues. So when a new module is released it would be nice to smoke all the modules that depend on that new module to see if they are still working. It will be hard or rather impossible to know who is at fault? Maybe the new version of the module explicitly says it is breaking its API in which case the module using it needs to be fixed. Gabor
