Redmine

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)?

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.

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) ?

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

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.

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

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.

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

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.