My two cents - this'll probably rile you up...
Don't ship until it works correctly or is the best you can make it. Nobody
needs 2.0 if they are working with 1.8 so there's no urgency. Don't pull a
Microsoft here and release something just "because".
You are just heading for a bad rap if you do. Fix the problems and get the
user interface up to par (you've seen my comments on this before). FlexWiki
has a long, long way to go before it will be a "wow" product, and most of
that path is making it work for business as a business tool, not as a social
commentary product.
Releasing a 2.0 version that, on the surface, is just 1.8 with some fixes
just isn't going to excite anyone in the Wiki world...
I've watched the way you guys have been working on this, and you are all
brilliant, so I just don't understand why you don't put your heads together
and spec out something that will really blow everybody away.
Otherwise, call it 1.9 and let it go at that.
JMO
Fred
_____
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Craig
Andera
Sent: Monday, October 15, 2007 1:14 PM
To: 'FlexWiki Users Mailing List'
Subject: [Flexwiki-users] I think we should ship RC0
It's been a bit quiet here lately. I've been on travel, but am back and am
working on FlexWiki again. So here's what I'm thinking: we never did reach a
conclusion about performance, other than to say that it's good overall, but
that there definitely exist cases where it's enough worse than 1.8 soas to
be unusable for some wikis. To that end, I've started working on an
implementation of output caching. It's going well so far.
But here's the deal: I don't think we should wait for it. I think we should
stamp the current bits 2.0 RC0 and ship them, with the idea that output
caching will simply not be part of 2.0. It'll be in 2.2 (2.1 will be an
"unstable" release). I think this is a good idea for several reasons:
1) I think that most wikis don't make use of the sort of heavy-duty
WikiTalk that has problems. Those that do are unlikely to run to thousands
of topics, which is when the problem manifests. Those that do should be
testing before deploying anyway.
2) In the open source world, there's a lot to be said for momentum.
That means shipping often.
3) Even when I do complete output caching, the first render is going to
be extremely slow for certain cases, unless we make radical changes to the
way WikiTalk is evaluated.
Here are the two other features I think we might want to have in an RTW that
aren't there now:
1) Web-based administration of flexwiki.config. Derek has this on his
list to do at some point. It's not a particularly big job.
2) Upgrade support. I.e. when someone installs 2.0 over 1.8, we could
try to slurp their values from NamespaceMap.xml and web.config into
flexwiki.config, to the extent possible.
Does anyone think shipping an RC0 based on the current bits is a bad idea?
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Flexwiki-users mailing list
Flexwiki-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flexwiki-users
