Re: upgrade to 3.2.1

So after weeks of part-time work resolving dependency issues in the 
upgrade (primarily with GMime and Glib, but libevent was also a minor 
issue) this evening I upgraded from 3.0.2 to 3.2.2.

I did make a backup of the database, but the schema auto-migration 
appears to have worked, things are operational, and I do not notice any 
ill effects with the database at this point.

(I'm hoping that the efforts of this upgrade result in no more 
situations where clients cannot connect to dbmail-imapd and dbmail-pop3d 
services.  Whether the problem was in dbmail or in GMime or something 
else, I don't know.  I didn't have any problems after upgrading only 
GMime, but I didn't let dbmail-3.0.2 run long-enough with GMime-2.6.20 
to say.  Normally I would see one problem every two weeks or so, but 
lately it was more-frequent: like once per-week.  I only finished the 
GMime upgrade on Thursday.)

I quickly hit-upon the dbmail-imapd segfault bug fixed here:

https://github.com/pjstevns/dbmail/commit/edd6179d638d4257d0a669de582f8770370a7364

So, I applied that patch, and it seems to have resolved the crashing 
problem.

Upgrade documentation is a concern for me, though...

The UPGRADING document and the sample dbmail.conf file explain that 
[dburi] has deprecated [driver], [host], [sqlport], [sqlsocket], [user], 
[pass], and [db].  However, no examples are given and no format syntax 
is provided.  So, it leaves the user guessing.  I'm sure that database 
URIs are probably standard, and dbmail adheres to this standard, but 
it's not stated.  I just followed the example in 
dbmail-3.2.2/jenkins/Makefile.

A IMAP behavior change from default, login_disabled=no to yes, is not 
discussed at all in UPGRADING.

Lastly, the UPGRADING file contains unnecessary information noise. As it 
is the user has to read the entire UPGRADING document and determine 
which parts apply to their upgrade path.  Since this is the 3.2.2 
tarball there is no need to explain the upgrade path to 3.0 as long as 
you include the full 2.2-to-3.2 path in the explanation.  Nobody is 
downloading the 3.2.2 tarball in order to perform a 2.2-to-3.0 upgrade.  
That information is only relevant so that those upgrading from 2.2 can 
try to discern what they need to do.  It would be clearer if the 
UPGRADING document did not expect the reader to decipher the noise from 
the information and merely explain what users of all previous versions 
of dbmail would need to do to upgrade and maintain the same functional 
behavior.

Thanks,

Lee.