>>>Would you prefer freshclam/ClamAV crash/corrupt memory when loading the new databases with >980 byte lines?
If it was impossible to support new functionality with a database compatible with ClamAV <=0.94, then the database should have forked -- two sets of databases generated by the automated database build process, one containing only signatures compatible with ClamAV <=0.94, and the other containing all available signatures, and the database update infrastructure should have been enhanced to be smart enough to know how to download the correct database for the installed ClamAV version. >>>The initial announcement about this was 6 month ago. If a 6 month window to upgrade is not enough, what would be? I'd say that obsoleting and remotely disabling mission-critical software that is less than two years old is unreasonable whether the software is commercial or OSS, and I'd say that doing so with anything less than a 1-year lead time is also unreasonable. In comparison, Symantec says (see http://www.symantec.com/business/support/Symantec_Support_Policy.pdf), "We generally provide Support Services for each 'Major Release' of Licensed Software for a period of up to seven (7) years from the date it first became GA." While seven years may be excessive for an OSS project, whose resources are obviously far more limited than those of a large corporation, I really think what was done here was excessive in the other direction. Not to mention that y'all really need to put some thought into your version numbering. A major incompatible change like this warrants a major version bump, and yet despite the fact that ClamAV has been in use by many sites in production for years and years and you've introduced many major changes during that time, you're still not even at version 1.0. There's something wrong there. jik _______________________________________________ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net
