0.93.6 vs 0.94.0

[David Relson]

Matthias,

I'm shifting this private thread to bogofilter-dev since I think it's
become of interest to the user base. 

On Fri, 25 Feb 2005 11:16:48 +0100 Matthias Andree wrote:

> On Thu, 24 Feb 2005, David Relson wrote:
> 
> > In my thoughts, the new release will be 0.94.0, rather than 0.93.6 because:
> > 
> >  1. the new run-time selection and auto-detection capabilities are significant
> >  2. the default mode will be non-transaction.
> > 
> > With a bit of history included, the reasoning is:
> 
> OK, some other bit of history reflected:
> 
> - we have traditionally released a new version (0.94.X) when we broke
>   compatibility, creating additional upgrade requirements and such
> 
> We are not breaking compatibility with the recent changes, so there is
> no reason to bump the minor revision, we can just bump patchlevel and be
> done.

Changing the default from transaction to non-transaction is my primary
reason for bumping the minor revision.

> > Bogofilter's 0.93.x series introduced 3 related changes:
> > 
> >  1. added support for Berkeley DB's transaction capability;
> >  2. used ./configure to select use/non-use of transactions; and 
> >  3. the default build uses transactions
> > 
> > With bogofilter 0.94.0 there are some changes:
> > 
> >  1. the default build supports _both_ transaction and non-transaction
> >     modes;
> >  2. command line and config file options allow run-time choice of
> >     transaction or non-transaction mode
> 
> 1. and 2. are a refinement of 0.93.X, to fix the "cannot share
> wordlists" problem.

Supporting both transactions and non-transactions is a "lock-in"
solution, i.e. it allows distribution of executables that don't lock
people in to transaction or non-transaction mode (depending on how the
package is built).

> >  3. if relevant options aren't specified, bogofilter will check for a
> >     transaction environment and will run in transaction (or
> >     non-transaction) mode (depending on the result of the check); and
> 
> >  4. ./configure can be used to create a single mode copy of   
> >     bogofilter, i.e. transaction-only or non-transactcion version (but
> >     not both)
> 
> I still see these as fixes of the problems earlier 0.93.X (have) caused.

Yes, run-time selection and auto-mode detection are fixes.  Having
"fTransaction=NO" is a change in default behavior and I think that
change warrants the change in minor version from 93 to 94.

> As the latest stable version is still 0.92.8, the next stable release
> should be from the 0.93.X branch, so we shouldn't bump to 0.94 without
> any stable release.

Not having a stable 0.93 branch is fine by me.  There's been a lot of
complaints associated with the 0.93 branch, i.e. storage usage (log
files), problems copying wordlist.db, etc.  With all the improvements
since 0.93.0, we _are_ very close to a stable release that won't
alienate our users.  

Having 0.94 be the release of "non-transactions for simple
administration; transactions for the advanced user" puts us very close
to a stable release that will make people happy.

> Our users are concerned with managability, and I think if we make them
> read the release notes of a version never released, they'll jump at us,
> and with good reason. That we changed things (like removing DB 3.1
> support) from 0.93.J to 0.93.K is no big deal as long as we don't do
> that again after a stable 0.93.M release.

One of our problems is that we can't make _read_ the release notes, even
for the current release!  There are still people who're running old
versions, for example 0.17.5.  When they upgrade, there is a lot of
reading that they _should_ do.  Having info on a "never stabilized"
version is a minor concern.

> _Please_ let's do 0.93.6. The release announcement can prominently point
> out that it is a "feel-good" upgrade.

We definitely need _something_ in this regard.  I fear that 0.93.x has a
bad reputation due to all the early difficulties people encountered with
log files and copying wordlist.db.  Changing from 0.93 to 0.94 is one
way to make clear that we've progressed beyond those difficulties.


> 
> Besides that, we should also leave TXN the default. The major concern
> users are having is with the log file management, that is resolved in
> CVS by defaulting to db-log-autoremove=yes.
> 
> Here's my suggested roadmap, chronologically
> 
> - revise documentation for db-log-autoremove, db-transaction (should
>   this be in the plural numerus, db-transactions, instead?) and the
>   run-time selectability; affects bogofilter.xml, bogoutil.xml,
>   README.db and perhaps other README files.
> 
> - remove compile-time switch altogether, the code size decrease is
>   irrelevant, it just causes too many ifs and buts. Perhaps add an
>   administrator configuration file that users cannot override.
> 
> * Milestone 1, release 0.93.6
> 
> - add "environment resize needed" detector to wordlist code
> 
> - add online resizer
> 
> - clean up character set conversion/mapping

Are these actually needed for the upcoming release?  How close are you
to having this working?

The charset.c code is satisfactory for now.  I've been experimenting with the
iconv code and it's not ready for prime time :-<

> * Milestone 2, release 0.93.7
> 
> This 0.93.7 could then become a stable version later on.

_______________________________________________
Bogofilter-dev mailing list
Bogofilter-dev at bogofilter.org
http://www.bogofilter.org/mailman/listinfo/bogofilter-dev