Zope 3.4 and the way forward
So, what's the way forward for existing Zope 3.4 (KGS) users? Rewrite our apps so we don't depend on anything in zope.app and switch to the ZTK? Band together and release a Zope 3.5 KGS, which would be a strict superset of the ZTK 1.0? Band together and release a ZopeApp 1.0 KGS which would be a strict superset of the ZTK 1.0? (In which case, why not call it Zope 3.5 KGS?) Forget all this open-source sharing stuff and maintain our own separate versions.cfg files with ad-hoc version mixes? Personally, I'd prefer option 1 (if there were docs to tell me what to do to get rid of zope.app, which is implausible) or option 2. Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development
Hey, Marius Gedminas wrote:
So, what's the way forward for existing Zope 3.4 (KGS) users?
Rewrite our apps so we don't depend on anything in zope.app and switch to the ZTK?
That's not possible as far as I can see, as the Zope 3.4 KGS doesn't support this. No zope.container yet, for instance, so no way to get rid of zope.app.container. It's only possible to start such an app rewrite once you're on the ZTK. (we don't know whether it's possible to complete such a rewrite. we will have to see)
Band together and release a Zope 3.5 KGS, which would be a strict superset of the ZTK 1.0?
Band together and release a ZopeApp 1.0 KGS which would be a strict superset of the ZTK 1.0?
Yes. Possibly a Zope 3.5 KGS that extends that further, I'm not sure.
(In which case, why not call it Zope 3.5 KGS?)
Because Grok can use the ZopeApp 1.0 KGS as well. So can Zope 2 users who need to upgrade away from zope.app packages. (I think!)
Forget all this open-source sharing stuff and maintain our own separate versions.cfg files with ad-hoc version mixes?
I'm trying to remember this open source sharing stuff and avoid ad-hoc version mixes where we can.
Personally, I'd prefer option 1 (if there were docs to tell me what to do to get rid of zope.app, which is implausible) or option 2.
I prefer option 3 (ZopeApp KGS), because there's a greater opportunity for that old open source sharing thing. And also because it would help us get rid of the somewhat confusing "Zope 3" terminology. Regards, Martijn
On 12/30/2009 12:17 AM, Martijn Faassen wrote:
Hey,
Marius Gedminas wrote:
So, what's the way forward for existing Zope 3.4 (KGS) users?
Rewrite our apps so we don't depend on anything in zope.app and switch to the ZTK?
That's not possible as far as I can see, as the Zope 3.4 KGS doesn't support this. No zope.container yet, for instance, so no way to get rid of zope.app.container. It's only possible to start such an app rewrite once you're on the ZTK. (we don't know whether it's possible to complete such a rewrite. we will have to see)
Band together and release a Zope 3.5 KGS, which would be a strict superset of the ZTK 1.0?
Band together and release a ZopeApp 1.0 KGS which would be a strict superset of the ZTK 1.0?
Yes. Possibly a Zope 3.5 KGS that extends that further, I'm not sure.
(In which case, why not call it Zope 3.5 KGS?)
Because Grok can use the ZopeApp 1.0 KGS as well. So can Zope 2 users who need to upgrade away from zope.app packages. (I think!)
Forget all this open-source sharing stuff and maintain our own separate versions.cfg files with ad-hoc version mixes?
I'm trying to remember this open source sharing stuff and avoid ad-hoc version mixes where we can.
Personally, I'd prefer option 1 (if there were docs to tell me what to do to get rid of zope.app, which is implausible) or option 2.
I prefer option 3 (ZopeApp KGS), because there's a greater opportunity for that old open source sharing thing. And also because it would help us get rid of the somewhat confusing "Zope 3" terminology.
Hmm. Just because I've been lagging and do get some newcomer questions here and there: is there an overview of what KGSs exist and what they "mean"? 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
On Wed, Dec 30, 2009 at 00:07, Marius Gedminas <marius@gedmin.as> wrote:
So, what's the way forward for existing Zope 3.4 (KGS) users?
I'm not one, so I really should shut up, but I won't. :)
Rewrite our apps so we don't depend on anything in zope.app and switch to the ZTK?
Band together and release a Zope 3.5 KGS, which would be a strict superset of the ZTK 1.0?
I think: Both of these. :) A 3.5 KGS that includes all the 3.4 packages and has deprecation warnings for the refactorings out of zope.app seems to me to be a great help in this. Then the 3.4 users can switch to 3.5, fix all the zope.app imports that are gone, and still have everything working. You can then look at your code and see how much you use of zope.app packages after such a refactoring. If that is "not much" then team up with Martijn who wanted to make a smaller ZTK publisher, or look into if you can use BFG's publisher. That's going to be more work, but I suspect most 3.4 users would be able to use it and end up with a smaller leaner app. But....what do I know. I'm just guessing. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
Hi Marius, On Wed, Dec 30, 2009 at 4:37 AM, Marius Gedminas <marius@gedmin.as> wrote:
So, what's the way forward for existing Zope 3.4 (KGS) users?
I hope you might be heard about "BlueBream". My ideas is to create a successor to "Zope 3". As part of this effort, I started working on a KGS based on zopetookit: svn://svn.zope.org/repos/main/bbkit/trunk Well, I don't want to speak more as we don't have anything to show. Anyway, here are few links: http://wiki.zope.org/bluebream/BlueBreamWiki http://bluebream.zope.org/doc/1.0/index.html BTW, I am fine if anyone focus on a ZopeApp KGS to upgrade from Zope 3.4 KGS. Then, BueBream will use that KGS. Regards, Baiju M
participants (5)
-
Baiju M -
Christian Theune -
Lennart Regebro -
Marius Gedminas -
Martijn Faassen