Plugins in Subversion -- Plugins Authors Please Note

All the existing published plugins have all been transferred into Subversion (SVN), svn trunk. The extensions are maintained in the SVN trunk. If you prefer not to use SVN you can publish extensions by attaching the ZIP file to its homepage in this Plugins web.

There are several reasons for this using SVN:

1. Subversion is the CM system of choice for the TWiki project.
2. Subversion is simple to use and well documented.
3. It is a lot easier to test the plugins in the context of a branch if they are in the same repository.
4. Many plugins authors have simply abandoned their plugins. Where nobody cares, that's fine, but some of the abandoned plugins are still interesting and useful. In Subversion there is a much higher probability they will be tested and maintained.
5. Some developers have the desire to branch plugins. TWiki 4 (DakarRelease) has a different, more extensive Plugins API, and several Plugins can be trivially recoded to be a lot more efficient with the new API. Of course when they are recoded, they will no longer work with Cairo, hence the desire to branch the Plugin.
   • IMPORTANT consideration: Many organizations do not upgrade their TWiki installation for quite a while, but might need new Plugin functionality. Therefore it is advisable to keep your Plugin compatible with Cairo and Dakar. This can be accomplished if you adhere to Cairo's Plugin API, and/or use conditional code (as described in SharedCodeDev). If you cannot maintain compatibility with Cairo, please ensure that the old version of your plugin that worked on Cairo is still available for download.

Any existing plugin author who intends to maintain their plugin can request checkin rights to the subversion repository. Please login first, then create <your name>WouldLikeToCheckIn giving a short introduction of yourself, and your reasons for requesting access. Please indicate if you want to check into the entire MAIN branch, or just the twikiplugins subdirectory

The vision driving all this is of a firefox-like plugins architecture, where it is trivial to go to the web and browse for plugins, trivial to install them, and perhaps more importantly trivial for plugins authors to maintain their plugins. Plugin developers should read DakarDevelopersPleaseNote to learn how to use the BuildContrib for easy plugin install/uninstall.

Note that there is an old TWiki plugin CVS repository on Sourceforge. This is no longer in active use.

We're not claiming that the plugins now in subversion are "good" - in fact, many are very bad and waiting for just the right guy to come by and bring them up to date.

Please see more details on creating and/or maintaining extensions using the current twiki.org SVN infrastructure at SingleBranchPluginDevelopment.

trunk and release branches.

As described above all extensions are maintained in the Subversion trunk. All new development of plugins on Subversion is happening only in trunk.

There are some special cases to pay notice to.

The default plugins, skins and other extensions that are distributed with TWiki are - like the core code - maintained in two place. Svn trunk and the current Release branch. And like the core code only bug fixes are merged into the Release branch. This means that the version of a plugin in the Release branch and trunk may not be the same. For practical reasons some non-default plugins are copied when a new Release branch is created (when a minor or major release of TWiki is released). But all the non-default plugins are not maintained in the Release branch!!

The follow rules applies for releasing plugins

• Default extensions are released from the Release branch! The version on twiki.org is always the version from the latest patch branch for default extensions.
• Default extensions are besides bug fixes merged to Release branch developed in the trunk. Beta releases for testing are built from the trunk and they can be uploaded and attached to the extension Dev topic for public testing purposes.
• If a default extension has been developed in trunk and it is decided that the change is to be released - it is important that the developer merges the new version to the current Release branch and release it from there to avoid that a later release of a TWiki patch version causes an unwanted downgrade of the default extension.
• Non default extensions are only maintained and released from the trunk.

-- Contributors: WillNorris, SvenDowideit, CrawfordCurrie, PeterThoeny, KennethLavrsen

Discussion

(Moved old discussion to PluginsInSubversionDiscussion for archival) -- RafaelAlvarez

I guess I don't quite get this whole thing. If I want to produce a plugin for TWiki, wouldn't I use TWiki to maintain it? I don't understand all this subversion stuff.

I figured out how to write a plugin, I found all the right libraries to call, I discovered all the undocumented stuff like function returns, and I added stuff to my plugin to try to make it more broadly useful. I could have just said "the heck with it", and just used it internally. but I thought that maybe I should give something back.

When I come here, however, I find that there is some kind of battle going on over what the right way is to do plugins. And it has something to do with subversion, which I'm expected to learn, and buildcontrib, which I'm also supposed to figure out. All in all, it just seems like way too much trouble for my one little plugin, so I guess I'll just hang on to it, at least for a while. They don't pay me to do this stuff, and I've probably already spent more time than I should on it.

I'm open to having my opinion changed, however! It just seems really difficult to contribute. BTW, my plugin allows us to create html meta tags, so our search engine will like our TWiki pages better.

I'll stop whining now.

-- DougClaar - 13 May 2006

Thank you Doug for sharing your thoughts. We need your voice. It should be as easy as possible for anyone to contribute back a Plugin, not just for professionals familair with source code management. This SVN stuff is primarily intended for people who work a lot on the code. If you simply would like to share your Plugin, by all means please do so in this Plugins web as documented. Not all Plugins are in SVN, e.g. you can create a Plugin topic and simply attach the zip file there.

-- PeterThoeny - 13 May 2006

Perhaps we should have stated more clearly that the old mechanism of "just upload it to TWiki.org" is still in place, that haven't change.

Even if we encourage plugins authors to use the SVN repository (easier to manage versions) and BuildContrib (automates several tasks related to plugins developemt), casual plugins developers that don't want to commit too much time to the TWikiCommunity or learning about SVN and BuildContrib and want to contribute back their plugins/addons/contribs can still just package their plugins, create the topic in the Plugins and upload there the package. This has not changed.

The battle that was "raging" is about how to manage the SVN repository in a way to keep it simple for all developers that use it.

-- RafaelAlvarez - 13 May 2006

Actually, the battle is no longer raging. This should be made clear by removing comments that suggest otherwise. And, yes, it needs to be made clear to casual developers, most of whom I assume are not using SVN, that they can continue to work as they always have been.

-- MeredithLesly - 13 May 2006

Well, I've contributed a Plugin. If it turns out to be ragingly successful, or needs to be updated, I'll look into this SVN thing--promise--but for now, I'm just getting my feet wet...

http://twiki.org/cgi-bin/view/Plugins/HtmlMetaPlugin

-- DougClaar - 31 May 2006