Theo Van Dinter writes: > Ok. Keep 3.1 the way it currently is, semi-revert 3.2 to have a rules > directory and we'll put a minimal set of 3.2 rules in there. > > External to the normal distro, we have code that generates updates based on > the mass-check results (or whatever else we want to base them on).
Aha -- so the "rulesrc" tree would become a place for *solely* version-independent rulesets. I like that idea. Couple of questions: What would we do with new plugin-based rules? I guess they'd have to be kept in each version's version-specific rule dir, right? (That's probably best anyway, I think.) Would you keep the mkrules compilation step, which "compiles" the rules dirs into an output format? It has some good advantages, like filtering out broken/non-linting rules files, renaming rules that collide with others, automatic "T_" prefix renaming for test rules, and avoiding having to add new multiple-rule-directory support code to Mail::SpamAssassin itself, among others. --j.
