Hi all 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? Regards Roger Ineichen _____________________________ END OF MESSAGE
On Monday 02 February 2009, Roger Ineichen wrote:
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?
The best would be to run all the tests of the 3.5dev KGS and see what tests are failing and start fixing those packages. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
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. 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. 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. Regards, Martijn
On Tue, 03 Feb 2009 01:49:25 +0100 Martijn Faassen <faassen@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@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
Hi Christian
Betreff: Re: [Zope-dev] How can we update our source?
On Tue, 03 Feb 2009 01:49:25 +0100 Martijn Faassen <faassen@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
participants (4)
-
Christian Theune -
Martijn Faassen -
Roger Ineichen -
Stephan Richter