Tags:
create new tag
view all tags
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:

  1. Install the required version in an SVN checkout area
  2. Add the files to SVN
  3. Change "PluginVersionInCVS" to "PluginVersionInSVN"
  4. 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:

  1. 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.
  2. 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.
  3. 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:
  1. TWikiStandardPackage plugins should be in SVN
  2. 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

Edit | Attach | Watch | Print version | History: r15 < r14 < r13 < r12 < r11 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r15 - 2006-10-08 - KennethLavrsen
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2026 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.