Minimum server version restrictions should ignore release status identifier


When loading a plugin that defines a minimum Openfire version as 4.1.3, that plugin will

  • fail to load on Openfire 4.1.2

  • fail to load on Openfire 4.1.3 Alpha

  • successfully load on Openfire 4.1.3

An 'alpha' version is likely to have the changes introduced that are the dependency of the plugin. We could add the release status identifier to the requirement definition, but that will look silly.

Instead, we should ignore the release status identifier when parsing the requirement, so that a plugin that defines 4.1.3 as a minimum requirement:

  • fails to load on Openfire 4.1.2

  • successfully loads on Openfire 4.1.3 Alpha

  • successfully loads on Openfire 4.1.3




Daryl Herzmann
June 9, 2017, 2:20 PM

I reviewed some previous commits in this space and am less concerned now about it.  Will merge.

Guus der Kinderen
June 9, 2017, 1:27 PM

When I'm creating or modifying a plugin to work with a recent change in Openfire core, I'd like to define the requirement by setting a minVersion for Openfire.

I now explicitly have to define the minVersion with an 'Alpha' qualifier, which is a) ugly, and b) not safe anyway, as older alpha's wont work, regardless.

Do you recall the change that we did around the 4.0 release that you're referring to?

Daryl Herzmann
June 9, 2017, 1:16 PM

I dunno about this change, but it likely won't hurt anything.  The alpha release status is immediately taken on with the next release.  For example, when 4.1.2 was released, the 4.1 Git branch immediately marched to 4.1.3-alpha.  I seem to recall we added code specifically for this check due to some plugins around the time of Openfire 4.0 release.  So I am sort of against this change, but I am not a coder and Guus supports everything he does way beyond reasonable expectations.



Dave Cridland


Guus der Kinderen



Expected Effort


Ignite Forum URL



Fix versions