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

[Roger Ineichen]

Hi Christian

> Betreff: Re: [Zope-dev] How can we update our source?
> 
> 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.

Thanks, sounds good to me.

Regards
Roger Ineichen