[Zope-dev] How can we update our source?

[Christian Theune]

On Tue, 03 Feb 2009 01:49:25 +0100
Martijn Faassen <faassen at startifact.com> wrote:

> Hey,
> 
> Roger Ineichen wrote:
> > First, thanks to the great refactoring work! 
> > 
> > Can someone give a summary about what got moved or is there 
> > another way to find out what I need to change in z3c and own
> > packages?
> > 
> > I guess there must be an update strategy since we skipped the 
> > deprecation message which I don't know. or not?
> 
> Basically I gave a description of what the major changes were:
> 
> zope.app.folder -> zope.site (for Folder), zope.container (for base 
> class to implement Folder, not typically to import from though)
> 
> zope.app.container -> zope.container
> 
> This information is also in the changelog of these packages and these 
> packages have undergone major (x.Y.z) releases.

Nevertheless we've put re-imports in place so current code should be
easy to get working again. With one exception: some dependencies were
cleaned up, and if you didn't declare your direct dependencies
correctly, you'll have to do some trial-and-error.

This is especially true for persistent classes for which the package
became obsolete. You'll have to add a direct dependency on the old
package containing that code and can remove it, once your persistent
data has been touched (I'm working on a tool for that, too).

> I think perhaps the zope3docs area should contain a document about
> major changes in the whole collection of Zope 3 libraries with this
> kind of information.

This reminds me a lot of what we used to write as proposals ... if we
had one, this would have been a good place to

- reference from the CHANGELOG
- describe what happened
- describe how to upgrade

> I think documentation of major changes is actually an upgrade
> strategy that we shouldn't ignore as a project. This is often better
> than seeing isolated deprecation warnings which sometimes even
> neglect to say what people should be doing, let alone why. A document
> can do so better.
> 
> In order to get hints about "better" import locations the test runner 
> (trunk) contains an option to let it report this information (you 
> imported something from here but in turn that actually comes from 
> somewhere else). This tool is not perfect (it cannot report on
> instances being imported, only classes and functions) but should be
> useful in finding hints of better import locations. It doesn't depend
> on the deprecation system. Christian Theune should be able to tell
> people more about this tool.

I'll write something as soon as I have the tests finished and this
stuff released.

Christian

-- 
Christian Theune · ct at gocept.com
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1
Zope and Plone consulting and development