https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6365
Daryl C. W. O'Shea <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #11 from Daryl C. W. O'Shea <[email protected]> 2011-05-20 05:37:40 UTC --- I've added a script to revert to an existing update version... build/mkupdates/revert-stable-update It doesn't solve the problem of making a fast new update, but it does give us the option of easily rolling back (reverting) to a previous update version. Reverting to an existing generally known to be good update should be our number one choice when trying to correct a rule update problem as were not rushing out a new update that could be broken in its own way. This works in cases where a new update introduces a problem, such as a new really bad rule. It doesn't help us in situation where an old rule turns bad for some reason, such as our little "Y2K10" rule issue from January 1 last year. In cases such as those (which I expect to be much fewer in occurence then the "new bad update" described above) we'll need to create and release a new update. I'll work on this case next. I think one possible way I may do it is that you supply a patch to the revert script for it to apply to an existing update (the script would unpack the existing update, patch it, pack it back up and re-sign it). -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
