[spambayes-dev] New release

[Kenny Pitt]

Tony Meyer wrote:
> It does seem that the interface may change significantly without
> sb_server or sb_imapfilter doing so (in fact, sb_server hardly
> changes at all anymore, but the interface changes lots).  But you can
> just kill it if you think that's better. 

My thought here was that even if it's only the UI that has changed, to
the average user the "application" has still changed.  The
pop3proxy_tray wrapper for sb_server supports the "check for latest
version" function, but it only checks the sb_server version and not the
interface version.  If we only increment the interface version, the
latest version check won't detect that the app has been updated.  End
result: whenever we increment interface version we have to increment the
sb_server version as well, so we lose any value that might have been
gained by knowing that the interface has changed but sb_server hasn't.

There have also been some bug fixes and additional options added to the
tokenizer/classifier which would affect the operation of sb_server
because it depends on those pieces.  As developers we like to know that
only the engine has changed, but to an end user it's still a new version
of sb_server.

Since these are the sorts of issues that are driving my thinking on the
versioning, I guess now is as good a time as any to try to present what
I've come up with so far.  This will be an off-the-cuff description of
the scheme, so I'm sure it will ramble a lot (especially since I tend to
do that anyway <0.5 wink>).  Let the discussion begin, if anyone is
determined enough to read through all this.

Whenever we've made enough changes to be worth a new release, something
in there probably affects every app in one way or another.  It's also a
little difficult to keep everything straight as users report issues when
different apps have different versioning schemes.  My proposal is that
all apps share the source release version as their primary version
number.  The shared release version would consist of the following
parts:

* A major/minor version number (1.0)
* A release number that would increment for each release.  If alpha9 is
our ninth release then the release number would be 9, but it would
increment to 10 for beta1.  The release number could be reset to 1 when
we move on to 1.1 development (although it wouldn't have to be).  The
purpose of this is to give us a three-part version number
major.minor.release that is always increasing.
* A string representation of the version ("1.0a9" or "1.0b1").  The
binary major.minor.release version would be used for version check
comparisons, but this string representation is what would be visible to
the user.
* A release date ("Feb 2004")

In addition to the shared version info, the engine and each application
would have a separate "revision number" that we would increment during
development to track changes specific to that app.  At a minimum, the
revision number would be incremented before each release if the app has
been updated.  We could also choose to increment it each time we make a
significant change to the app between releases, which might make it
easier to track the state for users running from CVS source.  Does
anyone think we should keep a revision date as well to show when the
revision number was last incremented?

For the complete version number of each app, the revision number could
be added to the string representation of the release version to produce
something like "1.0a9-004" for sb_server (actual format is, of course,
up for discussion).  The revision number could also be combined with the
binary release version to produce a standard 4-part version number for
use on Windows binaries (major.minor.release.revision).  As developers,
we know that we can always look at the revision number to see that
sb_server itself did not change between "1.0a9-004" and "1.0b1-004".

We should be able to use the same version numbering for binary versions
instead of keeping a separate version number.  If we need to release an
updated binary between source releases then we can increment the app's
revision number to indicate that, but I'm not sure what version number
to put on the Windows installer release if it contains more than one
app.  I'd also like to have Version.py do the check for binary or source
version when building the version description string rather than each
caller doing the check and selecting a different description format
string.

OK, I think that's more than enough to fuel the fire for now, so have at
it!

-- 
Kenny Pitt