Re: bogofilter behavior

[Matthias Andree]

Ted Zlatanov <tzz@lifelogs.com> writes:

> spam-strong and ham-strong means to unregister as the opposite before
> registering as spam/ham, implying that it's been registered already.
> At least this was the case before (or I was confused!).  I see that
> now it will be -Sn and -Ns respectively for ham-strong and
> spam-strong.

Since bogofilter 0.11.0, yes. This is not a recommendation to use any
0.11 version though although 0.11.2 would probably work somewhat.

0.5, 0.6 and 0.7.5 up to 0.10.3.1 used -S/-N for spam-/ham-strong, 0.7
to 0.7.4 used -S/-H for spam/ham-strong, -s/-h for spam/ham, 0.4 and
older didn't have the -strong options.

Looking at the NEWS file however I can only again discourage using
bogofilter versions that old. Missing features, missing tuning, missing
accuracy, and so on.

>> The users chose to use a development version, with all the implications
>> such as a minor release becoming incompatible with the previous,
>> anything but the current version unsupported, frequent updates and the
>> like.
>
> Sure, but if we *can* make it work, why be lazy?  It's such a small
> thing compared to bothering the user and getting misguided bug
> reports such as "spam.el doesn't work with bogofilter, I tested it!"

So don't just refuse work but tell the user that his bogofilter version
it too old.  Maintaining the illusion that the bogofilter versions
"works" will only cause more troubles in the long run than asking the
user to upgrade. After all, the user chose to install a young software
under development and he was prepared to bear the consequences, such as
non-functional releases, releases that break compatibility, and so on.

>> It's sensible to request frequent updates of users using a development
>> version. Don't waste your time on the 0.1 % of machines that run
>> outdated bogofilter versions - use the registration as mentioned above
>> and refuse work with versions before and excluding 0.11.0.
>
> I think this is wrong.  Not only does it put the burden on the user,

The user chose to install a developer version in the first place, and he
needs to face the consequences. Not your business.

Note that only the most recent "current" and the most recent "stable"
tarballs of bogofilter are supported upstream. Why would a third-party
developer bother to support a version that is unsupported by the
upstream maintainers?

> it also means that when bogofilter gets updated, spam.el needs to be
> updated as well.  That's crazy!

Why? Whether you use 0.11.2 or 0.92.4, -n -N -s -S are the
same. Versions before 0.11 used -S instead of -Ns and -N instead of -Sn.

The 0.12 versions brought support for mbox and batch processing, revised
in 0.15 which brought MH and Maildir support. 0.14 switched the data
base to one file which was found to be more efficient to handle.

No-one should run a bogofilter version older than 0.15.13 (released
2003-12-31) IMO.

Note well this whole post is my inofficial and personal opinion, not
that of the bogofilter team - users seem to be happy to upgrade.

> I'll either support Bogofilter as users expect it or not support it at
> all.

Users who have installed bogofilter have been aware it was a software
under development, and the versioning is not an issue on the bogofilter
mailing list.

>> It's not going to help anybody if someone uses some two-year-old version
>> of bogofilter today.
>
> Again, you're putting the burden on the user to upgrade.

Yes I do. _YOU_ are in no way obliged to support obsolete bogofilter
versions. I do believe your fear for bogus bug reports is
unsubstantiated if the refusal is worded properly, something along the
lines "Sorry, spam.el is not compatible with your older version of
bogofilter but has been developed with a more recent bogofilter version
in mind. If you plan to upgrade your bogofilter version; spam.el
requires at least bogofilter version 0.11.2, it is advisable to get at
least 0.15.13 though."

-- 
Matthias Andree

NOTE YOU WILL NOT RECEIVE MY MAIL IF YOU'RE USING SPF!
Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)