https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6365
Kevin A. McGrail <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #12 from Kevin A. McGrail <[email protected]> 2011-05-28 10:28:36 UTC --- (In reply to comment #11) > 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). I consider this solution as a good interim measure suitable to move this bug to a target of 3.4.0. Do you agree? -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
