dev_essential1Add my vote for this tag development1Add my vote for this tag plugin1Add my vote for this tag create new tag
, view all tags

Extensions in Subversion -- Extension Authors Please Note

Extensions are maintained in Subversion (SVN), 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 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 extensions in the context of a branch if they are in the same repository.
  4. Many extension authors have simply abandoned their code. Where nobody cares, that's fine, but some of the abandoned extensions are still interesting and useful. In Subversion there is a much higher probability they will be tested and maintained.

TIP Any extension author who intends to maintain their code can request checkin rights to the subversion repository.

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 extension authors to maintain their code. Extension 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 extensions 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.

IMPORTANT consideration: Many organizations do not upgrade their TWiki installation for quite a while, but might need new extension functionality. Therefore it is advisable to keep your extensions compatible with previous TWiki releases by adhering to the plugins API, and/or use conditional code (as described in SharedCodeDev). If you cannot maintain compatibility, please ensure that the old version of your plugin that worked on a previous release is still available for download.

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

Subversion trunk and release branches

As described above all extensions are maintained in the Subversion trunk. All new development of extensions 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 places, SVN trunk and the current Release branch TWikiRelease06x00. And like the core code only bug fixes are merged into the Release branch. This means that the version of an extension in the Release branch and trunk may not be the same. For practical reasons some non-default extensions are copied when a new Release branch is created (when a minor or major release of TWiki is released). But all the non-default extensions are not maintained in the Release branch!!

The follow rules applies for releasing extensions

  • Default extensions (extensions that ship with TWiki) 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


(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...


-- DougClaar - 31 May 2006

Edit | Attach | Watch | Print version | History: r41 < r40 < r39 < r38 < r37 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r41 - 2010-11-28 - PeterThoeny
  • 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-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.