upgrading a 2.2.12 murder to 2.3.14

[Andrew Morgan]

On Fri, 17 Jul 2009, David Mayo wrote:

>
> Andrew Morgan wrote:
>
>> On Thu, 16 Jul 2009, Gavin Gray wrote:
>> 
>>> We are planning towards upgrading our existing murder. The murder has
>>> four front ends, three backends and separate mupdate and lmtp servers.
>>> We want to move from version 2.2.12 to 2.3.14 so that we can make use
>>> of delayed expunge an possible replication.
>>> 
>>> 2. We should end up then with our existing murder but with three
>>> backends running 2.3.14. We then plan to upgrade the other machines in
>>> the murder to 2.3.14 in the following order: frontends then lmtp and
>>> finally the mupdate server. Does this make sense?
>> 
>> Whatever you do, don't upgrade any of your frontends while you have older 
>> backends.  The 2.3 code uses new IMAP calls that don't exist in 2.2. 
>> Quoting myself from a couple years ago:
>>
>>    I proceeded assuming I could have a v2.3.10 frontend with older v2.2.13
>>    backends.  However, I was unable to get the APPEND command to work.
>>    With telemetry logging enabled, I discovered that a 2.3 frontend issues
>>    the IMAP command "Localappend" to a backend.  However, my v2.2.13
>>    backend does not recognize "Localappend" as a valid command (and it is
>>    not present in the source code).
>
> We are in a very similar position to the Edinburgh guys except we have a 
> single IMAP server running 2.2.12. Our plan was to set up our new 2.3.13 
> back-end, use a 2.3.13 front-end, add the existing back-end to the new 
> Murder, then transfer our mail using xfer.
>
> Would it be more sensible to use a 2.2 front-end, move our mail to the new 
> back-end and upgrade the front-end to 2.3? Presumably there is no 
> "compatibility mode" for 2.3 that would make it issue only 2.2-compatible 
> commands? I'm surprised it can't work this out for itself.

Unless some special backwards compatibility was added since 2.3.10, you'll 
want to keep your frontend at 2.2.x until all your backends are upgraded 
to 2.3.

 	Andy