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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
