tri-state classification

[Matthias Andree]

"Pavel Kankovsky" <peak at argo.troja.mff.cuni.cz> writes:

>> I propose that bogofilter's default configuration be changed to use
>> tri-state classification with a conservative ham cutoff of 0.4 and with
>> bogosity tags of "Spam", "Ham", and "Unsure".
>
> This may be a nasty surprise for people relying on the current default
> config

Yes, it may. That's why we're still having a 0.X.Y version so we can
make sweeping changes that cause an unchanged configuration to barbecue
your pet and why we are bumping that X up whenever an incompatible
change occurs; and that's why stable versions with "higher" Y numbers
are around. We haven't bought into ESR's concept of calling "M.N.0"
versions "gold" because we know they aren't.

> Perhaps there should be some kind of transition period when bogofilter 
> would print a warning whenever it would use one of the changing default 
> values.

I'd try to avoid such.

> In fact, one might add a new directive to the config file, say
> "config_version", telling bogofilter what default values are assumed by
> the user, and bogofilter would either 1. use the right default value, or
> 2. print a warning when the current value has changed since the version
> the config file is based on.

I object. This seems to imply that the _code_ needs to carry around a
history of how configuration files or defaults were in the past.

I'd think just adding a version to the configuration file and printing a
warning (that points the user to check RELEASE.NOTES for incompatible
changes) if either the version line is missing or different from the
running code is reasonable and could be done easily though.

-- 
Matthias Andree