bogofilter version numbers

[Matthias Andree]

On Fri, 18 Oct 2002, David Relson wrote:

> I've been thinking that we _do_ need to change the version number more 
> frequently.  Last weekend, I was emailing back and forth with a 0.7.4 user 
> and we got all tangled up with switches.  The released version was still 
> using -h, -s, -H, and -S.  I knew that cvs had -n, -s, -S, -N as well as 
> new switches -h, -u, -l, and -e.  He swore he had 0.7.4 with -n, -s, -N, 
> and -S.  There was some confusion until we realized that he had the debian 
> cvs snapshot.  Changing version numbers more often would be very useful.

> One idea is to change the version number after _every_ code change.  A 
> second idea is to change it after any change that would be user visible - 
> new switch, algorithm change that might change the spamicity of a message, 
> etc.  Part of my thought is that changes that are strictly internal (for 
> example function name changes, changing from an if statement to a switch 
> statement, etc) might not need a version number change.

That's too much work and will cause whole-project recompiles, which I
consider "not helpful".

> Certainly, something that distinguishes the (experimental) cvs versions 
> from released versions would be very useful.

I'd suggest just leaving the .cvs there, and when someone makes a
release, then the .cvs tag is removed from the version in configure.in
only on the release branch, and I'd also suggest to reject bug reports
for any but the most recent CVS checkout or release are rejected.

I'm wondering if we could extract the bare dates from CVS somehow and
make one "versions" file, but I think that's too much effort unless
there is a global "build number" that is provided by the source or
configuration management. And yes, we've just bumped into the CVS
limits.

The above suggestions may look "not user friendly", but from my
experience with leafnode, it just takes too much effort to deal with bug
reports for old versions, and we don't do professional support for
bogofilter now (and even then, I'd rather not support development
versions that we have now on a contractual basis ;-)

-- 
Matthias Andree