[Zope3-dev] Zope 3 Roadmap thoughts

[Joseph Grace]

As a card carrying member of the uninitiated...

Jim Fulton wrote:
 >Tom Deprez wrote:
 >> And the transition of Zope2.0 to Zope3 should be as smooth as 
possible. I'm
 >> afraid that this is something very important (perhaps not in the 
eyes of
 >> developers, but through other eyes it certainly is)
 >
 >I don't know why you would think that this isn't important to 
developers.

Possibly because backward compatibility is apparently not explicitly 
paramount in the migration from Zope2 to Zope3.  Opaque answers like:

	>Can you describe this [migration tools, backward compatibility] more?
	Not really. The reason is that we made a concious decision not
	to be distracted by backward compatability during the design of 3x.

do not help much either.  As a designer, I can see the value in the 
"pure" approach.  However, as an uninitiated dependent on the Zope 
product migration, I find the opaque response unhelpful and unengaging.

Also, the roadmap seems confusing (especially with the years 
unspecified on many of the releases) and, due to cryptic version names, 
even misleading.  Who knows what a 3x is (or cares)?

Finally, your roadmap appears linear, but since automatic backward 
compatibility is not provided, the 2.x versions seem to dead-end 
forcing an abrupt reimplementation.  *Alarms*RedFlags*Alert*

This roadmap may make sense to the initiated inner circle, but to the 
rest of us it's just opaque, intimidating gobbledygook.

-=-

To change tacks, try:

1.  Simpler naming
	Zope2.x => 2.x (no change)
	Zope3x => pre.Zope2004
	Zope3.0 => Zope2004 (possibly becoming Zope3.0 upon final release)
     According to your roadmap, 3/1/2004 is reasonable for Zope3.0, so 
Zope2004 should be a logical, fairly self-explanatory and familiar name 
for the initial release (with about 9 months of leeway on the far side).

2.  Make a firm commitment on whether to support backward compatibility 
or 99.x% automatic conversion of Zope2 code into Zope2004.  Backward 
compatibility would be far more desirable as that puts the control of 
the migration in the hands of each project; they can "upgrade" and 
migrate code as desired, rather than wholehog.  If you *really* want 
smooth (as you suggest), then you will want full backward compatibility 
(or some very close, pragmatic approximation).
     To ease migration, the forward compatibility (backward migration of 
Zope2004 features into Zope2.x) will also be very desirable.  In this 
way, you may be able to sidestep some of the nastiness in backward 
compatibility issues: provide the forward features early so everyone 
can migrate out of Zope2 bog areas ahead of time.  This solution 
requires some strategizing to minimize the areas of effort, and to 
ensure the focus is on those portions which are most sticky (boggy, 
troubling) and important.
     If the forward features are highly desirable, then these features 
will market Zope2004 succesfully as well to the established base.

3.  Commit to supporting Zope2.x until Zope2004 achieves full backward 
compatibility (or reasonable facsimile of backward compatibility).  
I.e., make explicit the parallel development of live versions of 
Zope2.x with Zope2004 until full migration of community (modulo 12-18 
months or so) has been achieved.

4.  As someone suggested learning from MS, you probably do not want to 
hype Zope2004 too heavily until it's ready to roll out.  This issue may 
be more complex from your side (and as compared to MS) since this 
project requires volunteer help.  However, the people who find Zope2004 
most alienating are those who are ill equipped to help develop it 
(i.e., newbies, uninitiated, etc.) --- so it's no great loss to lose 
their direct contributions.  You just want them comfortable with the 
future and evolution of Zope (and their Zope dependent projects).
     The only thing I can suggest is finding a way to roll out Zope3 
incrementally.  Right now, it seems very whole hog and precipitous 
(again, to the uninitiated).
     As a design notion, I agree that Zope2004 should be designed in a 
vacuum to get the best design, but the commitment (and outward 
communication) needs to say that migration will be incremental and 
here's how (see above #1-3).  Perhaps there's a way to migrate Zope2 
code to Zope2004 over a series of versions (bringing full backward 
compatibility to Zope2004)?.  Somehow, pre.Zope2004 should be 
fulfilling this role but, from my reading of the list, does not seem to 
promise that.  That process could use some clear, comforting, and 
persuasive explanation (also, the 12-18 month parallel zope paths 
should help).

I hope some of this rings true even for the fully initiated.  
Otherwise, I apologize.

= Joe =