We do our best to make sure that plugins developed for an old version of RKWard will remain functional in later versions of RKWard. However, the reverse is not always true as new features are been added. Since not all users are running the latest version of RKWard, this means your plugin may not work for everybody.

When you are aware of such compatibility issues, you should make sure to document this fact in your .pluginmap file, using the <dependencies> element. The <dependencies> can either be specified as a direct child of the .pluginmap's <document> element, or as a child element of individual <component> definitions. In the first case, the dependencies apply to all plugins in the map. In the latter case only to the individual <component>(s). You can also mix top "global" and "specific" dependencies. In this case the "global" dependencies are added to those of the individual component.

Let's look at a small example:

<document ...>
	<dependencies rkward_min_version="0.5.0c" />
	<components ...>
		<component id="myplugin" file="reduced_version_of_myplugin.xml" ...>
			<dependencies rkward_max_version="0.6.0z" />
		</component>
		<component id="myplugin" file="fancy_version_of_myplugin.xml" ...>
			<dependencies rkward_min_version="0.6.1" />
		</component>
		...
x	</components ...>
</document>
	

In this example, all plugins are known to require at least version 0.5.0c of RKWard. One plugin, with id="myplugin" is provided in two alternative variants. The first, stripped down, version will be used for RKWard versions before 0.6.1. The latter utilizes features that are new in RKWard 0.6.1, and will only be used from RKWard 0.6.1 onwards.

Providing alternative variants like this is a very user friendly way to make use of new features, while still keeping support for earlier versions of RKWard. Alternative versions should share the same id (warnings will be produced, otherwise), and may only be defined within the same .pluginmap file.

Plugin which are not compatible with the running version of RKWard, and which do not come with an alternative version will be ignored with a warning.

Sometimes it will even be possible to handle version incompatibility issues inside a single .pluginmap file, using the <dependency_check> element, described in the following section.