bogofilter version numbers

[David Relson]

At 01:30 PM 10/18/02, Matthias Andree wrote:
>On Fri, 18 Oct 2002, David Relson wrote:
>
> > 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.

Our current versions are 0.7.5 (release-beta) and 0.7.5.1 (cvs).  Changing 
the cvs version to 0.7.5.cvs would be fine.

At the next release, the numeric part for both versions (release & cvs) 
should be increased.  My idea here is that x.y.z.cvs is x.y.z+ (plus).

We could extract the date from the CVS $Id:...$ line at the beeginning of 
each file.  For bogofilter we could pick either main.c or bogofilter.c (or 
have the script be smart enough to get the newer date of the two).  For 
bogoutil, the obvious file is bogoutil.c.  With an embedded date, we might 
have a version like 0.7.5-1018.

>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.

See above.  A script to generate filter-version.h and util-version.h (or 
some such names) and an appropriate dependency in Makefile.  The script 
could be smart enough to read config.h and find the "#define VERSION" and 
generate the *-version.h files (with a date included if the #define had "cvs").

Maybe I'll poke around and see if I can generate a reasonable version.sh 
script ...

>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 ;-)

Fine by me.


>--
>Matthias Andree