[Zope3-dev] Re: Zope 3 Roadmap thoughts
Jeffrey P Shell
jeffrey@cuemedia.com
Thu, 30 Jan 2003 15:02:45 -0700
On Wednesday, January 29, 2003, at 12:19 AM, Paul Everitt wrote:
> Jim Fulton wrote:
>> Hi,
>> Here is an update on my thoughts with respect to the timeline for
>> Zope 3 releases:
>> For Zope 3x:
>> - I'd like to release Zope 3x by September 1.
>> This will be a production-quality release of Zope 3x.
>> It will not be compatible with Zope 2 data or applications.
>> - I'd like to release Zope 3x beta 1 by June 1.
>> - I'd like to release alpha 3 by May 1.
>> - I'd like to release alpha 2 by March 1.
>> For Zope 3.0:
>> Note that Zope 3.0 will provide support for migrating
>> Zope 2 data and applications to Zope 3. This will probably take the
>> form of migration tools, rather than direct backward
>> compatability.
>
> Can you describe this more? I'm not exactly sure the depth to which
> Zope 3 can migrate applications.
>
> For instance, in Rotterdam I found out that the syntax has changed for
> getting parents in the request URL. Will the migration machinery
> check for things like that and convert it? (Note, there are probably
> a lot of little things like that used by people to build their sites.)
>
> How about things like CMF and DTML? For CMF, if I create three skins
> in my site with various layers and whatnot, will there be the logical
> equivalent to migrate it to? For DTML, if it exists in Zope 3, I
> think its syntax will change. Will people be able to migrate their
> existing DTML?
>
> IMO, we need to set expectations on migration before we discuss
> shipping a production-ready 3x. The discussion could have the
> negative effect that clients stop new Zope 2 deployments until they
> know what pain they are signing themselves up for. If you think they
> won't figure it out, well, competitors in the RFP process will, and I
> doubt they will portray it in a kind light.
>
> I've been talking to Kai Wu, a former engineering manager at ArsDigita
> who is now in the Zope community. His lessons-learned on the
> transition to ACS 4 might be informative:
>
> """
> The ACS never gained major momentum largely because, I believe, there
> were several major technology jumps (ACS 3, to ACS 4, then ACS Java,
> all within 2 years) that made it difficult for users and customers to
> keep pace and ultimately they lost trust in our management of the
> product. Even though we felt we had to upgrade the ACS "plumbing," of
> course this too-rapid rate of change entailed a host of other
> problems: missing documentation, missing functionality, client and
> user wait-and-see syndrome, and Faith That the Next Version Will
> Deliver Us (and users) From Evil that causes undue optimism on
> delivery dates - and compromises on quality that come back to haunt
> you.
>
> Zope2 and Plone let me do what I've always wanted with a web app
> framework: deploy a community and content-driven site quickly that
> looks great out of the box, with the knowledge that the technical
> engine underneath is powerful and flexible. I would hate to see a
> crippling loss of leadership and momentum around what already works
> and works well, with room to grow further still. With such a skilled
> and involved community, surely a way to continue wowing the world with
> Zope2/CMF/Plone can be balanced with a smooth introduction and
> long-term transition to Zope3.
> """
>
> IMO, we should give some priority to investigate ways to manage the
> transition. And we need to communicate more about this, so business
> people know what to expect, and feel comfortable using Zope 2, CMF,
> and friends.
There's not even that much communication about what Zope 3 is yet, not
something that business people are seeing anyways. This is a hard sell
- how to convince them that the current software is good when there's
all this talk about the architectural issues this big new release will
fix?
>> - I'd like to release Zope 3.0 alpha 1 by Dec 1
>> - I'd like to release Zope 3.0 beta 1 by Feb 1, 2004
>> - I'd like to release Zope 3.0 by Mar 1, 2004
>> This schedule will depend on the level of community desire for
>> and commitment to Zope 3.0.
>
> Yep, well said!
>
>> For Zope 2.0 and CMF releases:
>> I expect Zope 2.0 and CMF releases to continue well into 2004.
>> Zope 2.0 releases could extend farther if there is community
>> interest.
>
> With 2.6.0 and 2.6.1 betas, we've had trouble getting the releases out
> the door. We're having trouble, it seems, just in talking about the
> schedule. Does Zope 2 have a BDFL? If so, who is it, and will they
> be more active "well into 2004"?
>
>> I expect, as part of the migration effort, to start migrating some
>> Zope 3
>> technologies into Zope 2. I don't want this to slow Zope 3
>> development,
>> so I don't expect much to be done on this until this summer.
>
> On this point, I imagine I'm a contrarian on this list. But I'm
> willing to slow development of Zope 3 in support of smoothing the
> transition through backporting and related activities.
You are a contrarian! :P But seriously - I know that for us, few of
our existing sites would probably go over to Zope 3 soon anyways. It
was only recently that we moved a lot of older sites over to Zope
2.5.1. Once something is deployed, we tend to keep it running on what
works.
But as a developer and (sortof) a business person now, I *want* Zope 3
badly. It is much harder than it should be to write persistent
content/business objects in Zope 2 that need more than ZClasses offer
and can't afford the configuration time or speed issues of the CMF -
there's just too much to do, especially when wanting to really separate
the view/presentation layer so that the visual parts are editable
through the web but still get bound to the right context. It's doable,
but it's tricky. Based on what I've seen of Zope 3 thus far, I'm
positive that the development time for my current project would be cut
in half. (It's a small project, but it should take only one week
instead of two). When I run into situations like this, even my
long-standing belief in Zope gets shaken, if only temporarily. But I
look at Zope 3, and even commercial tools like WebObjects, and think
"man, I could get this up and running so much quicker if...", even
though I know that once I get through the painful phase I'm currently
in, everything will be much easier from here on than some of the other
tool names that are ringing in my head. Man, I *know* I could get this
up and running so much quicker if I only had Bobo/ZODB/Page Templates
on my side, but not the rest of Zope.
So, there's that point of view right now (but it may not be the best
time to catch me ;) - publishing business objects written in Python has
gotten way too difficult in Zope 2. And it's what my current task is.
But maybe I'm in the minority here. I want to move away from doing
sites that are just Scripts + Templates + SQL, but unless the job
really warrents the CMF, that's a difficult thing to fill (unless it's
something simple enough that ZClasses can handle it competently and no
SCM is required).
It's a really difficult situation because there are still plenty of
things that Zope 2 excels at. But it does get difficult to talk about
the virtues of Zope 3 in a way that doesn't make the current scenario
sound either (a) bad, or (b) so different that migration will be an
issue. I don't know how best to deal with that. I don't even know how
to worst deal with it, except to (maybe) rewrite the Zope 2 release
rulebook and get aggressive about backporting Zope 3 features. Make
the timeline aggressive enough so that it's like the current Zope 3
roadmap, but maybe pushed out a bit more, but doing quarterly releases.
Say ahead of time what will break or change in each release. *shrug*.
But something like:
Zope 2.7, March 2003:
- Brings new interfaces package and views from Zope 3
- 'context' can be used in Page Templates to refer to 'here',
using 'here' is now deprecated and *will no longer be supported
in Zope 2.8*
- FTP and WebDAV support methods in your classes should
move to view objects. Current FTP interfaces for Zope
should be considered deprecated, and will no longer be
supported in Zope 2.8.
Zope 2.8, June 2003:
- Services architecture shows up.
- Events, ObjectHubs, and such show up. Evaluate
usage of your 'manage_beforeDelete' calls*, copy
support calls, and catalog calls and start migrating
to using events and hubs where applicable.
- Classic FTP API's removed (or will raise serious
warning).
- Page Templates 'here' binding removed.
Zope 2.9, September 2003
- New TTW development system shows up.
- ZClasses marked as deprecated, but migration tools
exist to move to new TTW development (ie - map
property sheets to schema, Python Scripts to
module functions, or whatever). ZClass
support will remain throughout Zope 2 lifetime to
run existing ZClasses, but no new ones will
be addable starting with 2.10.
Zope 3X released in tandem with Zope 2.9
Zope 2.10, Dec 2003
- etc...
Zope 2.11, March 2004
Zope 3, March 2004,
Zope 2.12, September 2004
- Last real Zope 2 release, should have enough Zope 2
technology to keep running sites that went through
the painful but necessary "March to 3" updates, but
should have most new development occurring on Zope 3.
This is purely purely purely sci-fi of course, and would require
significant effort, but maybe we're having problems with the Zope 2.6
release cycle because there's just no need to be overly aggressive
about it (well, except for fixing some silly bugs in 2.6.0). If an
aggressive road map of Zope 2 releases existed, even ones with some
pain involved, they might be easier to stick to.
An alternative could be to release something like Apple's "Carbon
Library" for Zope 2 - a patch that starts applying changes like
outlined above, so that people interested in moving to Zope 3 when the
time comes can start doing the transition dance early while still
allowing Zope 2 to live out its days as it is living now for people who
just want to keep their old sites initially built and deployed on Zope
2.2 onto the latest and greatest Zopes to get security and performance
updates without breaking their sites. Again - purely sci-fi.
* I noticed 'manage_beforeDelete still exists in Zope 3 code. Why does
the 'manage_' concept still exist?
Now if you'll excuse me, I've got some cranky code to get back to. :)
> IMO, business people (who think differently than zope3-dev folks) will
> evaluate this whole Zope2-Zope3 situation using different criteria
> than us. I realize, though, that my opinion might be in the minority,
> so I'll try not to continually harp about it. :^)
>
> --Paul
>
>
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev@zope.org
> http://lists.zope.org/mailman/listinfo/zope3-dev