My head is starting to burst. The reason is that some plugins are checked in to both subversion ond CVS, some
TWikiStandardPackage plugins are not in subversion, some plugins have more recent versions than are in CVS, and versions are out of step.
Current status of
TWikiKernel plugins is:
| Plugin |
CVS |
Plugins web |
DevelopBranch |
Cairo |
DevelopBranch Note |
| CommentPlugin |
3.009 |
3.008 |
4.000 |
3.003 |
recoded for optimal performance |
| DefaultPlugin |
|
|
1.030 |
1.021 |
disabled JosWiki rules |
| EditTablePlugin |
1.023 |
1.024* |
1.025 |
1.024* |
load time optimisations |
| EmptyPlugin |
|
|
1.022 |
1.021 |
documentation improved and updated |
| InterwikiPlugin |
|
1.006 |
1.008 |
1.005 |
recoded for optimal performance |
| RenderListPlugin |
|
1.032 |
1.033 |
1.031 |
uses new handlers |
| SlideShowPlugin |
|
1.004 |
1.005 |
1.003 |
has load time optimisations |
| SmiliesPlugin |
1.002 |
1.004 |
1.006 |
1.003 |
uses new handlers |
| SpreadsheetPlugin |
1.012 |
1.016 |
1.017 |
1.013 |
load time optimisations |
| TablePlugin |
1.012 |
1.013 |
1.014 |
1.013 |
uses new handlers |
* - version in plugins web has same version number but is different to Cairo release
I don't like out of step versions, so I propose that plugins that are part of the
TWikiStandardPackage are moved into subversion. This suggests that the author of a plugin that is in the
TWikiStandardPackage must have at least
DevelopBranch checkin rights, but that's OK I think. I already moved
CommentPlugin.
The steps involved are:
- Install the required version in an SVN checkout area
- Add the files to SVN
- Change "PluginVersionInCVS" to "PluginVersionInSVN"
- Change the plugin topic
The plugin topic on twiki.org needs to be retained in case we need to post patched versions of the plugin. Note that since these plugins are in the
TWikiStandardPackage then
BuildContrib is not needed to build them. However, the unit tests have to be ported into the
TWikiTestInfrastructure (yeah, right, who am I trying to kid?)
--
CrawfordCurrie - 22 Feb 2005
In addition to simply moving the plugins into the repository, it makes sense to make these plugins "honest" i.e. eliminate all calls to TWiki core functions. In most cases this is only possible by adding new functions to
FuncDotPm. To support kernel plugins I need to add the following functions:
loadTemplate ( $theName, $theSkin, $theWeb ) -> $text
expandVariablesOnTopicCreation ( $text ) -> $text
registerTagHandler( $tag, \&fn )
getListOfWebs( $filter ) -> @webs
getPublicWebList( ) -> @webs
has been DEPRECATED - use getListOfWebs instead.
The implementation of all these is complete and checked in.
--
CrawfordCurrie - 23 Feb 2005
All the plugins in the
CorePackage have been refactored and brought into
SVN. They should really be removed from CVS, but SF doesn't allow that.
--
CrawfordCurrie - 05 Mar 2005
they can (and should) be
cvs remove d, though not expunged. it's almost never a good idea to actually delete the source history (especially if you didn't bring them in using
cvs2svn, but instead just added the latest version to
SVN)
--
WillNorris - 05 Mar 2005
I didn't use
cvs2svn because either they weren't up to date in CVS, or I didn't want the
BuildContrib cruft which is needed for plugins builds, but not for core builds (MANIFEST, build.pl etc). I'm still in a quandry about the best way to handle upgrades to plugins/contribs that are part of the core package. Should they be distributed via the Plugins web? If so, where should the
build.pl live?
--
CrawfordCurrie - 06 Mar 2005
The Plugins definitely need to be also in the Plugins web. The DEVELOP version is the bleeding edge, the Plugins web version is the stable version. People might want to upgrade just a Plugin with a needed new functionality, not the whole TWiki.
Still an unresolved problem is the versioning of the Plugins topic text. For the Plugins I maintain I plan to continue to build stable versions from my Alpha TWiki so that the topic revision is kept accurate.
--
PeterThoeny - 26 Mar 2005
I agree that plugins still need to be in the Plugins web, for the reason you give. There are a number of problems though, that I am grappling with. I'd like to hear other opinions. Here's how I see things.
The versions on DEVELOP are leading edge, yes. But there are changes in there that make significant improvements, such as the split into always-loaded and required modules, and use of the new
preRenderingHandler. These improvements make it impossible to take the versions in DEVELOP back into the Plugins web - they simply won't work with earlier TWiki versions. So, we have to accept that there at least two branches (as is the case for the core) - MAIN, and DEVELOP. At present, MAIN is split between
SVN for the core code, and CVS for the kernel plugins. This is bad practice, for a number of reasons:
- All the data used in a build must be controlled in, and drawn from, a version control system. There is a history of TWikiStandardPackage plugin versions not being checked into CVS, which is very dangerous. A zip in the plugins web is not an acceptable substitute - there is no reliable audit trail.
- A build should be executable from any node with just a checkout of MAIN - it should not have to rely on external data sources, such as TWiki.org.
- As can be seen from DEVELOP, plugins need to be able to branch, same as anything else. Maintaining branches in both SVN and CVS, and trying to synchronize them, is a recipe for problems.
So, I believe that:
- TWikiStandardPackage plugins should be in SVN
- It should be possible to branch and release kernel plugins as zips in the plugins repository, But the sources must be maintained in SVN.
BTW with the DEVELOP code, topic versioning for plugins topics is no longer an issue, as long as the installer script is run. That script checks in the new version to your installation. However this only works with DEVELOP, not Cairo, because DEVELOP does not rcs lock topics. More on this in
WhereAreDocsMasters.
--
CrawfordCurrie - 26 Mar 2005
i would like to
CheckAllPluginsIntoSourceControl and then
ConvertTWikiPluginsCvsToSvn
--
WillNorris - 22 May 2005
me too - especially as we now can't use twiki on SF, we may as well have the entire project hosted in one place
--
SvenDowideit - 22 May 2005
If anyone bumps into this topic by accident then please note that all TWiki plugins are maintained on
SVN in the MAIN branch. And only in the MAIN branch.
--
KennethLavrsen - 08 Oct 2006