You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@bugzilla.spamassassin.org on 2007/08/23 07:10:27 UTC

[Bug 5623] New: Implement versioning of plugins

http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5623

           Summary: Implement versioning of plugins
           Product: Spamassassin
           Version: SVN Trunk (Latest Devel Version)
          Platform: Other
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P5
         Component: Libraries
        AssignedTo: dev@spamassassin.apache.org
        ReportedBy: spamassassin@dostech.ca


Implement a way for:

 - plugins to declare their own version number
 - config code to check for a version of the plugin -- "ifpluginversion"

This will allow for third party rules and plugins to be distributed
independently of each other while allowing (in the rules) for the presence or
absence of features added to or removed from the required plugin.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 5623] Implement versioning of plugins

Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5623


spamassassin@dostech.ca changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|Undefined                   |3.3.0






------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

Re: [Bug 5623] New: Implement versioning of plugins

Posted by Theo Van Dinter <fe...@apache.org>.
On Thu, Aug 23, 2007 at 12:33:04AM -0500, Michael Parker wrote:
> I wanted to revisit unloadplugin.  Its been awhile since I messed with the
> config code but I think we load plugins right away on loadplugin.  What
> if during .pre parsing we didn't load right away, but waited until all
> the .pre files had been read and then loaded.  Then an unloadplugin
> would cause a pluging to not be loaded.

Sure, but fwiw, I would call it "noloadplugin" since you want to not load
something.  You can't unload the plugin afterall. :)

Feels like the type of thing that should have an RFE ticket open about it.

-- 
Randomly Selected Tagline:
I'm not a computer nerd; merely a techno-weenie.

Re: [Bug 5623] New: Implement versioning of plugins

Posted by Michael Parker <pa...@pobox.com>.
bugzilla-daemon@bugzilla.spamassassin.org wrote:
> Implement a way for:
> 
>  - plugins to declare their own version number
>  - config code to check for a version of the plugin -- "ifpluginversion"
> 
> This will allow for third party rules and plugins to be distributed
> independently of each other while allowing (in the rules) for the presence or
> absence of features added to or removed from the required plugin.
> 

I like this idea.  Also, while we're thinking about it in the code, I
wanted to revisit unloadplugin.  Its been awhile since I messed with the
config code but I think we load plugins right away on loadplugin.  What
if during .pre parsing we didn't load right away, but waited until all
the .pre files had been read and then loaded.  Then an unloadplugin
would cause a pluging to not be loaded.

I'd propose that unload takes precedence over load so in the case of
parsing several files order wouldn't matter.

Just a thought.  Who knows maybe I'll actually get some time to work on
it myself one of these days.  However, if someone happens to be digging
around in that part of the code I wouldn't mind seeing it.

Michael

[Bug 5623] Implement versioning of plugins

Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5623





------- Additional Comments From jm@jmason.org  2008-01-18 01:43 -------
thinking about this -- it might be better to define a way for plugins to set
"variables" that the "if" keyword can test.  e.g. a new version of ReplaceRules
could set "replace_supports_replace_foo" if it adds a new "replace_foo" keyword,
allowing


if (defined(replace_supports_replace_foo))
replace_foo bar
replace_foo baz
endif




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.