[rkward-devel] Importing external plugins (rk.power)

[Thomas F. <tho...@ru...>]

Hi!

So I have just imported the rk.power plugin from our external_plugins
repo, into the "main" sources. The import did not quite work quite as I
had hope, this time around, but essentially all relevant history was
preserved in the import.

Some issues / questions:
- What do we do about the imported plugin in the external_plugins
  repository? In general all changes should go to our main repo from
  now on, so the plugin should be removed in external_plugins. OTOH, we
  may want to defer deletion until RKWard 0.6.3 is actually released
  with the plugin - or even some time longer. Meik, as the manager of
  our plugin packages: What's best for your workflow:
    - Delete the plugin in external_plugins, right away
    - Keep the plugin in external_plugins for some time, but move it to
      some subdirectory ("imported")
    - Keep the plugin in external_plugins in its current path?
- The development version of RKWard supports plugins from different
  sources overriding each other (the one specified to have the highest
  version, _and_ compatible with the runtime version of RKWard will
  "win"). Of course, this works for plugins having the same id, only.
  Now, as an "official" plugin, the power plugin has the version of
  RKWard (i.e. will have 0.6.3), and id "rkward::power_analysis". Would
  it make sense to adjust the id on the current (external) plugin
  package, so that users that have installed it will not get a
  duplicate menu entry (after they have updated it)?
- Inheriting the version number from RKWard is a side-effect of
  rkwarddev writing <about>-info to the .pluginmap, instead of the
  plugin .xml. In general that is a good idea, too, unless - as in this
  case - no pluginmap is being generated. Is there a way to control
  this, already?
- I placed the plugin in analysis.pluginmap. As written earlier, if we
  have a good idea on just how to split up plugins in a meaningful way,
  that can still be changed. However, having separate pluginmaps for
  each and every plugin (i.e. > 100 pluginmaps) would have quite
  an impact on performance (and would be somewhat questionable,
  usability-wise, too, IMO). So, for now, I keep following the "big"
  pluginmap approach. Meik, with the new plugin management UI, and
  rk.set.plugin.status(), do you still consider this an issue?

Regards
Thomas