ANNOUNCE: CRITICAL BUG FIX RELEASE OfflineImap 6.5.0

[Sebastian Spaeth]

tldr; If you are on OfflineImap 6.4.x, please upgrade ASAP. Distro
maintainers, please bump.

Dear all,
after lots of recent reports of mysterious upload/redownload behavior,
and inconsistencies in our IMAP-IMAP mapping database, I investigated
and found a flaw when we:

- Upload multiple messages in one folder to an IMAP server a the same sync.

This concerns IMAP<->IMAP as well as IMAP<->Maildir.

The code fix, it turns out, was to remove one ", True", and occurred
because I did not consider the behavior of our underlying imaplib2
library (which is no excuse why it could happen though).

As a response, I herewith release OfflineImap 6.5.0 without much
testing, to get the bug fix out.

This is a CRITICAL bug fix release for everyone who is on the 6.4.x
series. Please upgrade to avoid potential data loss! The version has
been bumped to 6.5.0, please let everyone know to stay away from 6.5.x!
I am sorry for this. The gory technical details are in commit message
for commit 8fc72271895b7e46ad770417e2c5b8211f91eccd.

The Changelog for 6.5.0 is:

OfflineIMAP v6.5.0 (2012-01-06)
===============================

This is a CRITICAL bug fix release for everyone who is on the 6.4.x series. Please upgrade to avoid potential data loss! The version has been bumped to 6.5.0, please let everyone know that the 6.4.x series is problematic.

* Uploading multiple emails to an IMAP server would lead to wrong UIDs
  being returned (ie the same for all), which confused offlineimap and
  led to recurrent upload/download loops and inconsistencies in the
  IMAP<->IMAP uid mapping.

* Uploading of Messages from Maildir and IMAP<->IMAP has been made more
  efficient by renaming files/mapping entries, rather than actually
  loading and saving the message under a new UID. (This is a nice perf
  enhancement that made it to the next branch before the bug fix and
  thus stayed in).

* Fix regression that broke MachineUI

I would love if people gave this is try (use a test account or backup
your maildir if you don't trust it yet), to see if this fixes the bad
behavior.

After all the scary warnings, I would like to state that the chance of
actual data loss are slim to non-existent, but could be possible.

Thanks and sorry for that.
Sebastian

P.S. If this turns out to be more reliable, I will start to put out more
-rc candidates, as Nicolas had done, to get more testing before we
release a "stable"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/offlineimap-project/attachments/20120106/afe069ae/attachment.sig>