Add a Version Attribute to Plugin Feature Requirements

[HabariImporter]

Initially reported by: @chrismeller as #TRAC1324 You may have the plugin that provides feature x, but it might be an older version.

It would be useful to extend the pluggable XML schema to include a version attribute on both required / recommended and provided features.

[HabariImporter]

Author: @chrismeller This is similar to #1007, but relates to plugin APIs rather than Habari core's API.

[HabariImporter]

Author: @chrismeller Adding to the 0.8 wish-list.

[HabariImporter]

Ticket imported from Trac: http://trac.habariproject.org/habari/ticket/1324

[rick-c]

I'm not sure I understand the need for this. Isn't this supposed to be met by the features fields for the other plugins? If a feature does change between versions of the plugin drastically enough that it provides a different service, it should give the feature a new name.

[Mouvedia]

He's right, using the version directly in the feature's name would be easier.

[chrismeller]

Easier, perhaps, but more hacky and less flexible. Ideally I'd like to see something that allows more Drupal-like support - the ability to mark compatibility for an x or x.y version or above. Simply renaming the feature could accomplish this, but very inelegantly.

On Aug 16, 2011, at 1:55 AM, Mouvedia reply@reply.github.com wrote:

He's right, using the version directly in the feature's name would be easier.

ID3v1.1 => ID3v2

Reply to this email directly or view it on GitHub: https://github.com/habari/habari/issues/140#issuecomment-1813855

[Mouvedia]

There's one use case which warrants its addition: you want to support the feature but don't care about the version and someone else wants to support the same feature but for a specific version.

[rick-c]

Features should have a documented behavior. Given such and such and input, you get the specified output. Any other behaviour should be an undocumented side effect. Code shouldn't be relying on side effects. If the intent of how the feature works changes between versions, it's a different feature. Thus my suggestion to rename it.

[chrismeller]

I disagree. If I'm providing an "export" feature I'm providing a feature that allows exports. You don't necessarily need to know what version, but could in some situations. Just because I did a large update doesn't mean the feature no longer allows an export, it just means that the API might have changed. It also doesn't mean that previous code wouldn't necessarily work, just that there are more features available. You don't change the name of your plugin every time you update it, you just increment the version - features should work the same way.

[mikelietz]

What about flexibility in being able to put in an optional version if needed? So that some things that can really only be on or off wouldn't need to track versions, and other stuff that would (bundled libraries, changing APIs, etc) could and would?

[chrismeller]

Additionally, listing features would be highly confusing if you have multiple features for the same feature because you're incorporating the version attribute into the name. export, export1, export2, export25. Highly inefficient.

[chrismeller]

@mikelietz Version would always be optional, I never intended for it to be required.

[Konzertheld]

Are features not meant to show the plugin provides something another plugin might also provide, like spamcheck? If I require a spamcheck, I would not even require a certain plugin, not to speak of a version. So I also don't really get why we should provide versions. The feature thing is about flexibility and interchangeability, isn't it?