[spambayes-dev] beta release time?

[Tony Meyer]

> So, is there any reason we shouldn't do a first beta release 
> in the next week or so?

Heh - getting bored now there's no new Python version to release, huh?
<wink>

Mark's rough plan (back on the 28th of Nov) was:
> 1) Merge as above.
> 2) Let things settle for a week or so, so poor CVS users
> all get to suffer alone.
> 3) Put together a binary from my current py2exe setup script,
> which includes CVS and a number of sb_ programs.
> 4) Announce this binary as a "binary-beta", calling it 0.75 or something.
> 5) Any major bugs will presumably be part of the "binary framework", so
> maybe 0.76 etc, depending on the damage.
> 6) Move towards release 0.8 - this will be simultaneous
> windows-binary and source.
> 7) Move towards release 0.9 - aim for 4 weeks after 0.8,
> addressing only bugs.
> 8) Just *before* the 0.9 release, cut a new 1.0 branch.  Release 0.9.
> 9) Move towards 1.0, again aiming for 4 weeks, possibly with 2x release
> candidates.

Step 1 is done.  Step 2 is well done.  Step 3 is done.  I think step 4 is
done, too - at least Mark did announce an 'experimental' release of the
binary, calling it 008.5 (the binary was at 008, the source was at a7).
Either there wasn't much interest in this version, or there were few bugs,
since we didn't hear all that much.  So we can probably consider step 5
done.  This leaves us at step 6.

Mark's plan, of course, doesn't distinguish between 'alpha' and 'beta', just
prerelease (<1.0) and release (1.0).  I suppose that where there is "0.8"
above, that could be version 009 of the installer and 1.0b1 of the source,
"0.9" could be version 010 of the installer and 1.0b2 of the source.  Then
there's 011/1.0rc1 and 012/1.0rc2 and 013/1.0 (or is that 100/1.0?).

Anyway, this is a long-winded way of me saying +1 to a release in the next
week or so.  If we continue along Mark's plan, this means the next one would
be that time in Feb, and then a 1.0 in mid March, or so.  Whatever we do, it
would be nice to have the planned simultaneous source & binary releases.

> If people have bugs/features they 
> want fixed/added before then, can we assemble a list?

 * The Version.py stuff (Mark was going to do this at some point).
 * Command-line options, particularly -d/-D/-p.  It would be nice if this
was consistent :)  There's a patch (by Remi?) to make these consistent.
Skip's 'any option' option should probably be consistently available, too,
rather than just with sb_filter.
 * I *almost* have the autoconfigure script working on both WinXP and Win98,
and I'd like to finish that (I can probably do that this weekend).  It's not
actually used or advertised, but I'd like it in the release so that I can
get people to test it, if they are willing.

Recently, there's been a lot of discussion about training regimes, and what
we encourage users to do.  The web interface probably encourages
train-on-everything at the moment; if we are going to change that to
encourage nonedge or balanced training, then I think that shouldn't be done
between beta releases, so would have to be included.

=Tony Meyer