Hi Christian > Betreff: Re: [Zope-dev] How can we update our source? > > On Tue, 03 Feb 2009 01:49:25 +0100 > Martijn Faassen <faas...@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.
Thanks, sounds good to me. Regards Roger Ineichen _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )