Using the HEAD with old databases and code is a real adventure these days for these reasons: - It doesn't start, due to a tiny config bug which I'll check a fix in for shortly. - Many products create instances of the class Persistence.PersistentMapping.PersistentMapping which no longer exists (CMFCore's SkinsTool and CMFDefault DiscussionTool are two of these). These things either need to be migrated somehow to Persistence.PersistentMapping (*before* an update to the HEAD) or we need to provide some sort of b/c alias. That seems tricky given the current source layout. I've added an alias that seems to work: sys.modules['Persistence.PersistentMapping'] = sys.modules['Persistence.mapping'] But this is really odd because I don't know under what circumstance this alias shadows the effect of the line: from Persistence.mapping import PersistentMapping in Persistence's __init__.py module. If there is a shadowing problem with this alias, I'd suggest we go back to the old layout (where there really was a PersistentMapping.py module in Persistence) on the HEAD for sanity's sake. I'm sure there are reasons against this, but the other option is to require every CMF/Plone user to go through a really delicate migration before upgrading to 2.8, which doesn't seem like a good idea. - The HEAD apparently no longer allows URL access to methods that have inherited function docstrings, where older versions did. Lots of things depend for better or worse on this behavior and this breaks a lot of things. They are all shallow fixes (go add a docstring, typically) but it's difficult to figure out where you need to go do this. - The ZODBMountPoint product relies on a method of Connection objects named _getMountedConnection, which apparently no longer exists. This breaks any mounted databases (which breaks dbtab, which breaks sessions, which breaks lots of other things). Hopefully this is simple to fix, I haven't looked yet. - ZopeVersionControl doesn't work anymore due to various ZODB changes. - Various security declarations that used to allow access now deny. Bug reports don't get any more vague than that, but then again nobody's security machinery is any more vague about reporting its reasons for denying access than Zope's. ;-) I can try to make headway on some of this. Is anyone else willing to help? FWIW, after working through (and around) some of these issues I was able to get Plone running on the current HEAD (well, at least plope.com, which uses a lot of Plone), so I can happily report that Zope 2.8 isn't 100% backwards-incompatible yet. ;-) dig-the-hole-and-fill-it-up-again'ly y'rs, - C