> Ahh of course, the problem is not code migration, but data > migration, hmmm.
Hmm indeed! > I tried to find some code of how this had been done on earlier > occasions of > upgrading the Mailet API, but without luck. Is this really the > first time the > serialization format of Mail has changed? Not exactly, but in principle yes. This time we have to acknowledge that there is a large userbase who have expressed concern when upgrading James already about minor incompatibility between repository versions, without the API changing. > Okay, what about this approach to readObject/writeObject, that > would solve the > problem in a way eliminating the need for a data migration tool: If it works I see no reason why not to do it this way, So.. if you can produce a method by which mail in existing repositories can be converted on-the-fly Good! go right ahead. The way things work are that your changes will be reviewed by some of the comitters to make sure they are _basically_ OK, then they'll be comitted, and can be modified as time goes on. In other words its a collaborative process. Therefore basic functionality is OK for the HEAD if it is sensibly designed and appears to work, wrinkles can be ironed out in the longer term. d. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
