Zope, Plone and Python; Redux

[Jonathan Steffan]

It's getting close to the Fedora 8 freeze and I need to figure out what
I am supposed to do with Zope and Plone. With direct regards to Fedora 8
(and 7,) we don't have the needed python version and thus we have no
Zope and Plone. Please, let's not start that fire again. This message is
regarding what to do with the Fedora Core 6 packages and also the EPEL5
packages. The following is a brief outline of the issue:

Zope, Plone, Python in Fedora Core 6:

- Python 2.4.4
- Zope 2.9.8
- Plone 2.5.3

Zope, Plone, Python in Fedora 7+:

- Python 2.5
- No Zope
- No Plone

Zope, Plone, Python in EPEL5:

- Python 2.4.3
- Zope 2.9.8
- Plone 2.5.3

Zope, Plone, Python in EPEL4:

- Python 2.3.4
- No Zope
- No Plone

Plone 2.5.x require Zope 2.9.x and thus Python 2.4.3+. This means that
our only target releases are EPEL5 and FC6. Plone 3 is on the verge or
release and I'm getting everything in order to have the packages ready
for release. Plone 3.x requires Zope 2.10.x and we can sneak by with
Python 2.4.3, but 2.4.4 is recommended. This means, again, our target
releases are EPEL5 and FC6. In the past I have not maintained Plone
release N-1 ... just the most recent. I really prefer this, but I know
it is not best for the Zope and Plone developer base. To express why,
look at how strict the above requirements are. Some things will continue
to need the Plone 2.5.x release which will be maintained until Plone 3.5
is ready. Also, Zope is very useful for more then just Plone and there
are actually four (maybe more) active branches of Zope; 2.9.x 2.10.x
2.11.x and 3.x. 2.9-11 (IMHO) are the most used, but Zope 3 will still
be used by many. This brings us to the point.

What do we name all these packages? Currently we only have zope and
plone. How am I supposed to manage all these different versions
successfully? Who decides which branch continues to be "zope" and
"plone" and what do we name the others? How would end users have any
idea about packages other then "zope" and "plone"? Assuming migration
works, do we always just push forward to the latest usable version? Do
we restrict updating the zope package when plone requires version
1.2.3.4 but can not use 2.x? (as an abstract example).

There are zope 3 packages up for review:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235672

They are named zope3. Assuming we can make it so zope and zope3 don't
conflict, which I have not looked into, do we need to name zope 2.9.x
zope29 and zope 2.10.x zope210? How do I manage to expose to the end
users zope and plone will remain at the 2.9.x and plone 2.5.x as long as
they are maintained and then offer 2.10.x and plone 3.x as zope210 and
plone3? How do I migrate users away from the standard "zope" and "plone"
packages. We can not expect them to upgrade/update at any given point in
the updates stream and, for example, plone 2.1.x had issues migration to
plone 2.5.x once they got far enough away from each other so I was
unable to update FC4 before it went EOL.


On to even more of an issue. With the current packages we provide a
"default" instance that is normally upgraded as updates come out. How do
we provide the same enjoyable functionality when working with
incompatible versions installed at the same time both requesting the
same default instance space? I really like the zope3 packages having
zope3-instance, but we don't have that luxury in the current packages.


Assuming we have no power to force users to update at any time (aka
infer a package update "stream",) is there any way we can move to doing
something like plone25 and plone30 (and plone35) along with the needed
zope29 and zope210 and zope3, splitting out the default instance into a
subpackage?


</rant>

I, as the package maintainer, don't have a clear idea of how to deal
with this. Thanks for any feedback. As a last minute, right before
pressing the send button idea, do we keep the "zope" and "plone"
packages just the latest and then provide zopeXYZ and ploneXYZ as psuedo
"compat" packages? I'm in *no* rush to maintain all of this, but I find
great value in both of these pieces of software and would like to keep
Fedora and EPEL a fertile ground for such great software.

Jonathan Steffan