Feature #2162

Add additional fields to plugin registration

Added by Eric Davis almost 9 years ago. Updated almost 9 years ago.

Status:ClosedStart date:2008-11-11
Priority:NormalDue date:
Assignee:Eric Davis% Done:

0%

Category:Plugin API
Target version:0.8
Resolution:Fixed

Description

I'd like to add some additional fields to the plugin registration (Redmine::Plugin.register)

  • author_url - url to the author's website
  • support_url - url to use for requesting support for the plugin
  • redmine_version - list of Redmine versions that are supported by the plugin.

This would also include a few UI updates on the Plugins section of Information to display the new fields.

Associated revisions

Revision 2036
Added by Jean-Philippe Lang almost 9 years ago

Changes version naming rule (#2162).

Revision 2041
Added by Jean-Philippe Lang almost 9 years ago

Adds url and author_url plugin attributes (#2162).

Revision 2042
Added by Jean-Philippe Lang almost 9 years ago

Adds Plugin#requires_redmine method so that plugin compatibility can be checked against current Redmine version (#2162).

History

#1 Updated by Jean-Philippe Lang almost 9 years ago

What do have in mind concerning redmine_version?
A simple string or an array of versions that could be matched against the actual Redmine version (eg. to warn user if the plugin does not seem to be compatible)?

#2 Updated by Eric Davis almost 9 years ago

Yes. The hard part will be the logic to check the compatibility. I was going to open a new feature request about this since it's not entirely related to this feature but I'll post a quick summary of what I've seen here. Sometimes the Ruby process might not load at all (e.g. missing the Hook class) or it might only partially load (e.g. Hook class found but missing a call_hook).

I can think of two behaviors for when a plugin isn't compatible:

  1. Abort starting Redmine - bit extreme but would be the easiest to catch all the potential errors
  2. Prevent the plugin from loading it's files, print a message to the console, and maybe display the plugin's name in the Information panel but with message saying it isn't compatible.

Option 2 would be more user friendly but it would require messing around with Rail's loading mechanism.

#3 Updated by Jean-Philippe Lang almost 9 years ago

I would prefer a more generic plugin_url rather than support_url.
What do you think ?

Concerning version checking, I think that 1. would be fine for the 0.8 release. And maybe we could make something smarter in next release (of course, it wouldn't change the plugin API).

Here is the method I propose:

requires_redmine(options)

Where options is a Hash containing one or more of the following keys:

:version_or_higher   -- requires the given version or above
:version             -- requires one the given versions

Examples:

requires_redmine :version => [0,7]                   -- requires 0.7.x
requires_redmine :version => [0,7,1]                 -- requires 0.7.1
requires_redmine :version => [[0,7,1], [0,7,2]]      -- requires 0.7.1 or 0.7.2 (won't start with 0.7.3)

The problem is: how to check this against a trunk checkout (eg. 0.7.devel) ?

#4 Updated by Eric Davis almost 9 years ago

Jean-Philippe Lang wrote:

I would prefer a more generic plugin_url rather than support_url.
What do you think ?

Agree, that's what I thought but I must have typed "support". Main reason is I don't want people to log plugin bugs to redmine.org if there is a support site for the plugin.

Concerning version checking, I think that 1. would be fine for the 0.8 release. And maybe we could make something smarter in next release (of course, it wouldn't change the plugin API).

Here is the method I propose:

requires_redmine(options)

That looks good.

The problem is: how to check this against a trunk checkout (eg. 0.7.devel) ?

I think it might just be best to have a 'devel' version for requires_redmine. We could try to specify rxxx but there are so many ways to get the trunk version(1) and it would be overly complex. If the plugin author says, 'devel' then it's up to the author to handle any problems between trunk and their plugin. What do you think?

1: You could get trunk via svn checkout, svn export, my git clone, plus any of these using a third party repository (e.g. merging custom changes).

#5 Updated by Jean-Philippe Lang almost 9 years ago

The problem I see is more like this:

the author adds this to his plugin:

requires_redmine :version_or_higher => [0.7.1]

and someone who uses Redmine 0.7.devel wants to use this plugin.
Maybe its 0.7.devel is higher than 0.7.1, maybe not.

#6 Updated by Eric Davis almost 9 years ago

Jean-Philippe Lang wrote:

and someone who uses Redmine 0.7.devel wants to use this plugin.
Maybe its 0.7.devel is higher than 0.7.1, maybe not.

Good point. What if Redmine's version always had the major, minor, and tiny but then had a flag if it's the development copy? Then the plugin author would just target the current version or (if they rely on unreleased code) they would target 'devel' only.

(Note: syntax is a bit funky still. If we had devel, it might make sense to make it take an array of strings ["0.7.1.devel","0.7.2"])

# Would work with 0.7.1, 0.7.1.devel, 0.7.2, 0.7.2.devel...
requires_redmine :version_or_higher => [0.7.1]

# Would work with 0.7.1.devel, 0.7.2...
requires_redmine :version_or_higher => [0.7.1.devel]

Then during the release process the development flag would be toggled off in the branch:

  1. Increment version in trunk
  2. svn cp to the stable branch
  3. Turn off "development" version
  4. Tag x.y.z

#7 Updated by Jean-Philippe Lang almost 9 years ago

What if Redmine's version always had the major, minor, and tiny but then had a flag if it's the development copy?

Done in r2036.

#8 Updated by Jean-Philippe Lang almost 9 years ago

url (instead of plugin_url) and author_url plugin attributes added in r2041.

#9 Updated by Jean-Philippe Lang almost 9 years ago

redmine_version - list of Redmine versions that are supported by the plugin

Method Plugin#requires_redmine added in r2042. It raises an exception if requirement is not met.

#10 Updated by Jean-Philippe Lang almost 9 years ago

  • Status changed from New to Closed
  • Resolution set to Fixed

Everything seems to be done. Reopen if needed.

Also available in: Atom PDF