This is to give an idea of Zwiki development plans for 2008.

2008/02 list thread:

All -

thanks for the interesting feedback on, zope/plone-user lists and #zwiki channel. Based on this I see the following as a good roadmap.

  • Plone needs native wiki-ish solutions that fit the Plone model. It's time to stop chasing Plone, remove the [PloneAndCMF|CMF/Plone support]? (simplifing code and skins), and focus on plain Zope 2 as our platform.
  • Ideally there would be one last release to fix cosmetic issues with current Plone 3 support. Anyone who wanted Zwiki in Plone would use this version. This, call it Zwiki Classic, would enter mothball/deep maintenance mode. (We might call it 1.0. Don't freak out. I'm just saying.)
  • New development would focus on a 2.x branch where we would drop backwards compatibility, do very aggressive cleanup and generally make our life easier. Other priorities would be all-unicode, ease of hosting, pluggability and modularisation, moving to zope3 technologies, and extracting reusable python/zope3 libs. This would be a refactor not a ground-up rewrite - we should be able to use it pretty much right away.
  • Z3wiki (the all-zope3, ZPL zwiki codebase) might be able to use and help extract libs from above. I don't expect to work on z3wiki directly myself because Zope 2 is our mainstream appserver and because I prefer to spend most of my time in GPL-land.

So there is one possible path into the future, though I don't yet know how far down it we'll go. has a hundred subscribers, but I'm not hearing strong support/interest/need. And there are other projects and other implementation strategies to explore. One basic issue is that with wikis proliferating and traffic intensifying, 100%-dynamic, memory-intensive wikis are not always economic. Eg for slashdottings and for busy developers, an RCS-based solution like ikiwiki is attractive. And so on. Just pondering; we shall see. As always, further thoughts welcome.

2008/04 GeneralDiscussion:

My current thoughts:

  • as far as possible, stick with one main line of Zwiki development, rather than two. This is just simpler all round.
  • the stable and unstable repos are a good idea, especially for my hosting setup; I can test newer code in production while also hosting stable sites. I imagine all unstable patches feeding into stable eventually, and all Zwiki releases coming from stable.
  • keep Plone support. Refactor it, don't spend cycles supporting it, but keep the working code we have. Even partial Plone integration that just works is useful.
  • refactor ourselves into a modern component-architecture application. As that is achieved, it will open more integration possibilities.
  • within the "one main line", do mark major transitions with a version number change, eg to 1.x or 2.x. I think the switch to unicode is such a transition. I don't know exactly what we should do. I lean towards releasing one or more updates in the 0.x line, skipping 1.x entirely, and then releasing 2.0 with unicode support and some significant other features worthy of a 2.0 release. Also this should coincide with a fairly major overhaul of, jettisoning a lot of old content, possibly focussing it on 2.x and leaving as the 0.x support site.