By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,742 Members | 1,227 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,742 IT Pros & Developers. It's quick & easy.

migrate from ZODB 3.3.1 --- to where, and how?

P: n/a
Hello,

I am using ZODB "standalone" in version 3.3.1 within some application.

Now I learn that the 3.3.x branch of ZODB is "retired". No problem so
far, everything is running fine.
BUT... "retired" gives me the hint that nothing GREAT will be done to
this branch anymore :)

Now I am questioning myself: to which branch should I migrate? Is 3.5 a
sure bet, or are uneven subversions a bad sign, making retirement
likely?

As much as my diggings showed me, the "special sign" of 3.3 was
import ZODB
from persistent import Persistent
from persistent.list import PersistentList
from persistent.mapping import PersistentMapping

that PersistentList and PersistenMapping reside within
persistent.<something>, while in the 3.2 branch they reside somewhere
else in the namespace.

I learned it the hard way that 3.3 filestores not get converted
magically or easy to 3.2 :) ...

So, my questions:
- where should I migrate to?
- how is migration done best (especially taking care of "old"
filestores

Harald

Oct 25 '05 #1
Share this Question
Share on Google+
1 Reply


P: n/a
[Harald Armin Massa]
I am using ZODB "standalone" in version 3.3.1 within some application.

Now I learn that the 3.3.x branch of ZODB is "retired". No problem so
far, everything is running fine.

BUT... "retired" gives me the hint that nothing GREAT will be done to
this branch anymore :)
More than that, there will never be another release of any kind in the
3.3 line. ZODB work (I'm ZODB's primary maintainer, BTW) is driven by
Zope's needs. When the last Zope that needs a particular ZODB is no
longer supported, the ZODB used by that Zope is also no longer
supported. The ZODB 3.1 and 3.3 lines are dead now, corresponding
(respectively) to the Zope 2.6 line and an early experimental release
of Zope3.
Now I am questioning myself: to which branch should I migrate? Is 3.5 a
sure bet, or are uneven subversions a bad sign, making retirement
likely?
Whether digits in a release number are even or odd has no meaning in
ZODB (or Zope) releases.

You should be able to move to the 3.4 or 3.5 lines without problems.
ZODB 3.4 corresponds to the Zope 2.8 line, and ZODB 3.5 to the Zope
3.1 line. By the end of this year, ZODB 3.6 will be released
(corresponding to Zopes 2.9 and 3.2, which will also be released by
the end of the year). ZODB 3.7 (along with another batch of Zopes)
will be released mid-year 2006, etc.
As much as my diggings showed me, the "special sign" of 3.3 was
import ZODB
from persistent import Persistent
from persistent.list import PersistentList
from persistent.mapping import PersistentMapping

that PersistentList and PersistenMapping reside within
persistent.<something>, while in the 3.2 branch they reside somewhere
else in the namespace.
ZODBs at and before the 3.2 line differ in many ways from ZODBs at and
after the 3.3 line. So far, the 3.3, 3.4, 3.5 and (not yet released)
3.6 lines are pretty much intechangeable (although, of course, later
releases add features that may not work under earlier releases, and
because the 3.3 line is dead now it doesn't even get critical bugfixes
anymore).
I learned it the hard way that 3.3 filestores not get converted
magically or easy to 3.2 :)
As above, many things changed starting with 3.3.
So, my questions:
- where should I migrate to?
I'd jump to 3.5.1 now if I were you, and to 3.6.0 when it's released.
- how is migration done best (especially taking care of "old"
filestores


Moving from 3.3.1 to 3.5.1 should "just work".

Note that ZODB has its own mailing list:

http://mail.zope.org/mailman/listinfo/zodb-dev

Like most Zope lists, you have to subscribe to it in order to post to
it, but anyone can read the archives.
Oct 25 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.