Released as TWikiRelease01Feb2003
Next Release codenamed CairoRelease
The future production TWikiRelease
(old code name AthensRelease
) is code named Beijing. Its production release will be called TWikiRelease01Feb2003
, and due to arrive in late January, 2003.
This document fixes the feature set of what we can accomplish in this time. After Beijing the CairoRelease
is scheduled to arrive in mid 2003.
Lesser wanted features (i.e. feature requests where code changes are difficult and the requester has not contributed code) are less likely to be implemented in the near future. Moral: get someone to code your change and make it available in a way that is easily incorporated by the CoreTeam
TWiki is already a well advanced collaboration platform. New releases should be in line with the TWikiMission
as outlined in ReadmeFirst
. The Beijing Release should focus on pushing the envelop in giving broad corporate appeal
, without sacrificing the guidelines. Important key areas are the plugins and skins.
Focus for Beijing Release:
- Evolutionaly add smaller features and fix defects while keeping the product on a stable level.
- Some EnhancedPluginHandling where plugins can interact better with the TWiki core code.
Please note that the feature set of BeijingRelease
has been cut-back in order to expedite another release; the features cut are now set for CairoRelease
List of features and fixes that should go into the Beijings Release. The CoreTeam
should update this list.
"Nice to Have" List
All: Please add other features you would like to see in the Beijing Release. The CoreTeam
will evaluate what is possible. Also see category topics DocsToDo
for potential items of interest.
Change Proposals for BeijingRelease still being worked on
Search for topics that still need work:
Change Proposals for BeijingRelease Awaiting Merge
Search for topics Proposed for BeijingRelease that are waiting for merge to the MAIN branch:
Change Proposals for BeijingRelease Merged to Main SVN Branch
Search for topics Proposed for BeijingRelease that have been MergedToCore
Release State Summary
See also BeijingReleaseSummary
Feedback and requests
We need help testing! Please check DevelopersNews
for the latest Betas (registration required). Codev.TWikiAlphaRelease
s don't require a registration.
- 15 Jan 2003
Please add below. We need to decide on the strategy, feature set and schedule.
- 04 Dec 2001
On 27 Feb 2002, PeterMasiar
But even without that, what we already have, TWiki deserves new release.
Can I ask (beg) CoreTeam to add possibly some ready patches, and roll out BeijingRelease?Pretty please? Who is with me? We want BeijingRelease!
At two releases per year, we are going to make the other one hard work at this rate.
Perhaps the core team is overstretched? Maybe it is time to introduce a shared responsibility for releases? CoreTeam
- if people offered to take this responsibility, would you accept? What would the work entail, is the process documented and how much effort would you reckon for this release?
- 09 Jul 2002
We want BeijingRelease
, where are you?
- 11 Jul 2002
Don't worry, we are here
, just very busy and can't spend hours a day on TWiki
I am currently certainly very busy with other stuff, but try to keep up as good as I can.
Best chance to get enhancement requests included in the code is by submitting tested code. TWiki has a high quality standard, the core team cannot take any code just like that into the core.
Yes, it is time for the BeijingRelease
. We might need to skip some features to speed up the process. What needs to be in is SimplerDefaultTemplates
and a a little EnhancedPluginHandling
- 12 Jul 2002
To have SimplerDefaultTemplates
will be excellent! Many newcomers (like me
) also complain that topic
should be renamed to page
to anything, like maybe zone
). IMHO it may increase appeal and help to get buy-in
. It might be good time to settle page/topic and web/zone issue now, because we (I can volunteer time for it now) will need to review all docs and refer to action links on new, simpler templates. It looks to me that CoreTeam
is reluctant to get involved into this discussion?
- 12 Jul 2002
All this focus on appearance (SimplerDefaultTemplates
) doesn't seem (that) important to at least 1 user. I'm having problems getting serious uptake of twiki as a part of our systems (more than getting users to enter content) by being able to confidently say - yep, I can do that on the wiki. "Do that" usually means to do something a bit more sophisticated re. content organisation that a free-form wiki. To do this SearchWithAnd
are essential. Treat this as a (completely selfish
)vote for release soon - drop features.
- 17 Jul 2002
Rather than getting BeijingRelease
out the door, maybe a new Beta could be released. The reason
I am asking is that there have been changes (well at least one change, ConfigurableLogo
add RenameTestWebToSandboxWeb to the list --JohnRouillard 30Jul2002
to TWiki in TWikiAlphaRelease
that needs corresponding changes in the TWiki web and pub files. I have been trying to track
all the changes and pull them from twiki.org, but my new twiki still isn't configured quite right.
Alternatively, is there someway to get the files in pub and TWiki web that correspond
to the current TWikiAlphaRelease
- 29 Jul 2002
We need to name the next two releases and push back any features that we know for definite are not going to be in BeijingRelease
. It's August here in Kuala Lumpur.
- 1 Aug 2002
OK, lets decide on the code name for the upcoming releases: See Vote in CoffeeBreak#CodeNamesAfterBeijingRelease
Also, it is time for the next Beta release. RichardDonkin
, do you have time to finish up SettingLibPath
before I create the next Beta?
- 02 Aug 2002
How far is to to next BETA? I would like to install TWiki on my mm-void.sf.net tommorow
(including some of the plugins for DMOZ and discussions),
but I can wait an extra week if this would give me some of the new features.
Peter any esstimates???
- 03 Aug 2002
is now in CVS - seems to work for the testing that I've done, but since the code is the same for all scripts it shouldn't cause problems. The
script on donkin.org has been using it for months anyway ...
- 03 Aug 2002
Refactored lots of discussions out to MoreBeijingDiscussions
since this topics got quite long.
- 10 Aug 2002
Tagged a huge number of features (marked DeferToCairoCandidates
) to be dropped from Beijing release. Note that I am going by the completion status, the feature might be finished for all I know!
I therefore urge you to update the completion status or forever hold your pieces.
Unless I hear noises of disapproval, I will cull the feature list on the 21st August.
- 14 Aug 2002
I have the time and motivation to implement the changes in RenameMainWebToHome
, provided somebody knowledgeable can give me pointers in the right direction. Is the core team interested?
- 14 Aug 2002
Guys, it seems very unusual that the given focus for the Beijing Release was:
And we are defering 2 of these to the Cairo Release (EnhancedPluginHandling
Im all for tossing features to get a release out, but given the current inability to get these done (which was the focus) in the Bejing release, why do we think they could get done in Cairo.
Anyone for making the Cairo release strictly limited to a very few items (such as these) and making it a quicker release and leaving the Dakar release for a larger set of features.
- 14 Aug 2002
Agree with MartinCleaver
. It is better to have a less feature-rich release with more regularity than getting all the features in. There is no harm in deferring features if we can agree to make releases more regularly. Every half year seems to be a good interval, given the rate of change I have observed.
- 18 Aug 2002
Hi all, sorry for being late on this one, I am in Indonesia where the Internet Cafes are few and far between, the connections often bad and the cost expensive
It's a nice place though and well worth a visit.
As promised, I have cut out any item that I'd previously marked as a DeferToCairoCandidate
. I know that this will disappoint some and possibly annoy others but several changes have been made to the alpha and have been proven on TWiki.org that would benefit many and there doesn't seem a lot of point holding back this release just because the other objectives were not met.
It does seem a shame that Beijing Release didn't fulfil on its main objectives, which were:
Please take a look at the completion stats for tables above showing the cut-back feature set and comment if you think there is anything else that can be usefully delayed. If we are all set then it will be down to the CoreTeam
to create a beta for widespread testing.
- 24 Aug 2002
I've added UsingFormsForSettings
, as they have 0% code complete. The completion stats look much more tenable now.
If there is no objection I will cut these features from this document tomorrow.
: can you please create the BeijingReleaseBeta
or tell us how we can help to get this out? Thanks
Also, we say we are adding the CommentPlugin
to the core, I presume and hope this doesn't mean stopping making it a plugin? I think it would be clearer to talk about the 'standard distribution' or standard bundle, I recall seeing this mentioned elsewhere.
To Do: check through KnownIssuesOfTWiki01Dec2001
to ensure everything that can be closed off has been.
- 27 Aug 2002
: All users who signed up for the twiki-dev mailing list are informed where to get the latest beta, currently 03 Aug 2002 as indicated in the DevelopersNews
. People not on the list can request the Beta as usual using the download form.
Cut features: Martin, I appreciate your enthusiasm and your help in expediating the release, but directions should be agreed on with the CoreTeam
. I agree that we should cut features in order to speed up the release. However, the docs are currently way back. While the docs are being updated we can bring in some high priority feature enhancements. The one we should work on in a limited way is EnhancedPluginHandling
. We should defer all other major ones like EnhancedSkinHandling
Adding the CommentPlugin
to the core: Once the Plugin is stabilized we can add the Plugin to the core (not BeijingRelease
). It will remain a Plugin but will be included in the release, same as the InterwikiPlugin
- 27 Aug 2002
Good, I'm glad that we are agreed that most features can be put back. I agree that having EnhancedPluginHandling
is desirable - as long as getting another release out by the end Q3 is feasible.
WRT documentation: How far off are we? Have we a process for tracking it? Can I do a query to track? (e.g. I note that some items have category 'DocRequest' is this for that purpose?)
We have had several people offer their help on things; is there documentation they can assist with? I feel we should be doing more to help them help us!
: can we feature freeze this now, or at least agree on a date by which we can?
WRT Adding the CommentPlugin
to the core: My comment was about the use of the terminology 'Core'. I think 'Core' should be distinct from 'standard bundle' where 'standard bundle' refers to core + plugins et al that is released in each TWikiRelease
. Such a definition of Core thus excludes standard plugins such as InterwikiPlugin
- 01 Sep 2002
Not sure if it is too late for new requests for inclusion now - probably, if the aim is to release by the end of Q3
- but I'd like to see the OmittingEmailInWebNotify
patch added so users can just add their username to WebNotify
rather than having to add name + email address. I've been running with this patch for a couple of weeks and it works well.
As an aside, not entering the email addresses is also a useful (if minor) anti-spam protection on public sites as you don't want a lot of email addresses on a single web page - the current Codev.WebNotify
page here for example would be very easy to harvest for addresses.
- 28 Sep 2002
What's the current schedule for this release?
- 30 Oct 2002
Not sure if it is too late for new requests for inclusion now... there have been many complaints about the placement of the form change button, see ChooseFormButtonIssues
. I have made some minor modifications that move that button next to the "Preview Changes" button, and serve as either "Change form" or "Add form" button, depending on whether a form is not present or not, see MoveFormButton
. I believe this is cleaner from a user interface point of view (button in the same place in both situations), and leads to less likelihood that a user mistakes that button for the preview button...
I'd be willing to produce the patch (now done against verison on SourceForge
as of 10 Nov 2002, see MoveFormButton
) and do the necessary testing if instructed as to what the threshold of acceptability is. This is installed at our internal TWiki.... There are no backwards compatability issues...
- 10 Nov 2002
Docs for SettingLibPath
are now done, see TWikiInstallationGuide
under step 1. OmittingEmailInWebNotify
docs are also done, as an update to TWikiSiteTools
has better support for TWikiOnUnix
, see CVS:bin/testenv
- 10 Nov 2002
Lets shoot for a New Year's release 01 Jan 2003. That means, only safe code changes should be done
- 03 Dec 2002
Whoopy doo. One release a year. How exciting.
- 04 Dec 2002
I don't know who you are (and I guess you don't want to be known), but a comment like the above is not appropriate. The developers (and I am not one -- a wannabee, maybe, after I learn Perl) are all volunteers, and do this work in their spare time, with various motivations.
If you want releases more often, help in some way. Learn to program, or, there are ways to help if you can't / don't want to program. I don't know all those ways, the developers can surely suggest some -- maybe test some of the alpha or beta releases.
Here's a suggestion -- offer a cash reward for the next release, or for some specific feature (or start a reward pool).
- 04 Dec 2002
Hey, Randy, good word. Let me see...what does that word "collaborative" mean? Oh, yes, I remember -- "collaborate: to work together, esp. in a joint intellectual effort."
- 07 Dec 2002
Well, on balance, TWiki's aims include having two releases a year, and the last 12 months have yielded none; the AthensRelease
was Dec 2001, BeijingRelease
is scheduled Jan2003. So, ironically, the anonymous comment above is wrong.
Why the lag? The aim I stated in July to get a release out mid-year was not agreed by the core team and enough people seem happy with that to not make it a major issue (though there were some voices from people agreeing that a new release would have been nice). In the last few months, a process to make the TWikiBetaReleases
more widely available has been put in place, I guess this addresses most peoples' wants.
My main concern now concurs with JohnCavanaugh
's comment on EnhancedPluginHandling
, that the spec for that feature is not properly discussed, let alone settled, coded or documented. I'd like to see progress on that to be comfortable that the 2003 release is going to meet its schedule.
- 08 Dec 2002
I agree with Randy - the CoreTeam
is only a few people, all of whom are quite busy in other ways. If there were more and higher quality patches (see PatchGuidelines
) to the core code, following the core code style and providing general solutions not just quick hacks, the development could well go a lot faster. Also, submitting a lot of good patches is a sure way to risk getting invited onto the CoreTeam
Working on documentation is very useful and will help get releases out more quickly - if you can understand a new feature by reading the discussion page and testing it in TWikiAlphaRelease
, why not head over to TWiki:TWiki
and add its documentation in the appropriate place? If you aren't sure where to do this, comment on the doc page itself or on the feature page.
Testing is also very useful - particularly when BugReports
are well written and easily reproduced, and ideally come with a good-quality patch
are now freely downloadable, and you can get a TWikiBetaRelease
very easily by submitting the download form (link on TWikiBetaRelease
) and saying you want to test betas.
As Randy said, not being able to code is no excuse for not contributing!
- 09 Dec 2002
Is there some discussion on upgrading TWiki?
- 11 Dec 2002
(Moved Doug's comment from TWikiBetaRelease
for an initial upgrade doc. Help in refining it is appreciated.
- 17 Dec 2002
The core team has added loads of improvements in this release, especially around internationalisation
But, this page rates EnhancedPluginHandling
as 50% of the spec complete. Is it really 50% spec complete? Do we mean the proposed changes on MorePluginHooks
? Are they complete?
As (quoting Peter) only safe code changes should be done
, why not just drop it and get BeijingRelease
out the door?
I see nothing wrong with not finishing all that we intended. If we can move on we can celebrate getting the internationalisation changes out, everyone's production systems onto a new version and start afresh at features we are not ready to complete yet.
What you say?
- 21 Dec 2002
In an effort to get a feel for completeness in this yuletide season, I've taken the liberty of updating the above tables:
- I split the table into complete and incomplete.
- I've said ScriptToCreateNewWeb is 50% complete. There are instructions but they are not consistant as how to create a new web appears multiple times in different places. It would be helpful if someone could turn AddingANewWeb into a page of its own and update the references.
- 21 Dec 2002
I narrowed the scope of EnhancedPluginHandling
down to PluginApiForTopicHandling
. This is in the interest of the release coming up shortly.
- 29 Dec 2002
Three items in the "Nice To Have" are at 100% complete. Do they need to be checked into a different place in CVS before they are moved to "Objectives Complete?" The features are MultipleAttachmentsAtOnce
- 09 Jan 2003
Only code that has been commited back into CVS is considered 100% complete by the CoreTeam
. The 100% by the contributor means that the code is ready.
- 09 Jan 2003
I noticed that Plugins
points to a TWiki web topic TWiki.TWikiAddOns
that doesn't exist. I added it to the "Nice To Have" set. Since it's a document I didn't know whether to put the CVS at 100% or not.
- 10 Jan 2003
Which plugins will be included in standard Twiki distro?
I would like to ask at least for all plugins tested and enabled here on twiki.org: SpreadSheetPlugin
. If they are stable enough, let's spread them. If the is any concern about stability/performance, it's easy to disable them, right? Or they might come as disabled, and admin will enable them.
Why I am asking for this? We all know that Twiki is not as easy to install as it should. And we can see many would-be admins struggling with Twiki nstallation. So why in this struggle not install them many nice features they might want to install later anyway? Plugins might be copied in proper places, ready to be activated. Maybe disabled - but easy to enable if needed.
- 11 Jan 2003
The TWiki production release currently has three Plugins preinstalled: EmptyPlugin
. Over time we can add additional Plugins. However, I do not see the value of adding many Plugins, since (1) Plugin installation is simple, (2) each installed Plugin degrades the performance by a few percent, and (3) preinstalled Plugins will be outdated by the time a release comes out because Plugins evolve quickly.
One Plugin that should go into the release is the TablePlugin
, and possibly the SpreadSheetPlugin
. May be we should start a VoteOnPreInstalledPlugins
- 13 Jan 2003
I think it's a great idea to include some of the common plugins by default, pre-configured and ready to go. (1) I think you over-estimate the skills and/or the "percieved ease of install" of many folks installing TWiki!, (2) I suspect the percieved value will be incredibly high compared to performance changes, and (3) having functionality (even if upgrades are needed) is WAY better then not having them, especially in the beginning when people don't know what a plugin, skin or addon is. I commonly hear that TWiki is tough to install, but I rarely if ever hear that installers need more flexibility.
I can imagine different plugins would be included for different reasons. Perhaps this would be a good discussion to begin evolving on the Plugins web unless you just want to decide right now for Beijing and not worry about designing a feedback process. Now that I write this, I think we just need to get a release out ASAP. I look forward to seeing a best-practice for voting!
- 13 Jan 2003
Please note that I am aware about possible performance impact of plugins. I asked plugins be packed into distribution (so all pieces will be placed in proper places when installing), but disabled it TWikiPreferences
page. Then admin can enable what she needs, without all the pain. If old stable version is enough, no additional effort is needed. Or, if she decides to upgrade, at least there are files in place to guide what needs replacement.
Please do not underestimate anxiety of a windows person typing first time
. I know what I am talking about.
Deleting plugin name in list of disabled plugins is much
simpler - trust me.
- 14 Jan 2003
Whoa, I didn't realize there's a potential legal issue with the logo. I'll need to review HighResolutionLogos
to catch up on this issue.
... and why did I laugh so hard when I read this? http://c2.com/cgi/wiki?BigBangTesting
- 17 Jan 2003
- can you please confirm for me that RcsLite
is ready for this release? It looks like I have to use it for the TWikiOnDebian
package for security reasons (twiki files should be owned consistently by twikidat not apache user)
- 26 Jan 2003
is fairly complex and so until a few users have reported success the following in
# RcsLite - use a 100% Perl simplified implementation of Perl (NOT yet ready for production use)
There are lot of tests in
- a good starting point would be to try these. I will look to fix any problems.
- 26 Jan 2003
The latest ETA from PeterThoeny
for a release is still (very) late January! If you have the time an inclination (and know English pretty well
), please take a look at the status above and help out with documentation for the remaining items this week.
- 28 Jan 2003
I am declaring InternationalisationEnhancements
complete - the only missing parts are quite esoteric and can be fixed at a later date if anyone actually notices them. This code has been running for some time at http://donkin.org/
enabled, and at TWiki.org without I18N
, so it is reasonably stable IMO.
As for the docs for the remaining bits, I am unlikely to get any time at all for these in the next week or two, due to change of role at work and integration with another company, resulting in very long working days - so I would like to invite anyone interested to start writing the docs for this, RefreshEditPage
There is already a lot of documentation for these issues in the relevant pages and
, it's mainly editing into TWiki:TWiki
docs - I suggest:
I'm happy to review docs, please email me if there are major updates. Remember, you don't have to be a programmer to contribute to TWiki!
- 01 Feb 2003