Hi everyone.
I am proposing to extend the Moodle plugin's version.php meta-data with $plugin->impediments array to define other components that the plugin can't work together with.
Please see the draft spec at https://docs.moodle.org/dev/User:David_Mudrak/Draft:_Plugin_impediments and reply here with your comments and potential objections.
Thanks in advance.
Is this going to lead to an implied requirement for plugin creators to test against every other plugin though? I can foresee the comments in the forums - this plugin has now been found not to work if you have x other plugin installed - 'Well, it doesn't say that in the version.php, so I assumed it should/would.' And therefore, the expectation that if it doesn't state explicitly in the plugin version.php that it will work with everything else.
Is there potential for creating unrealistic expectations of testing for plugins with this?
I can see that way Tim, I just think we need to be careful to manage expectations (not just of other developers, but of the huge number of site admins who install these plugins)
There have been one or two examples, but the ones I have seen almost always come down to one of the plugins being incorrectly coded (e.g. not loading javascript the accepted way) and really needs one of the plugins to be fixed rather than notified as 'incompatible' in my opinion. The instances I recall have all been fixed very quickly by notifying the plugin developer and they have fixed the issue. One other example was my own flexibase theme breaking when the parent (Bas' bootstrap) was updated and it was preferable to fix the issue rather than specify a maximum version of the parent, even if this feature had been available.
test against every other plugin
That is interesting point. Surely not, indeed. As Tim notices, this particular plugin-plugin collision use case is actually very theoretical given that both plugins follow the naming conventions etc.
Better use cases for this proposal are really those other two: ability to define the maximum version of the core or the other plugin that the plugin needs. Especially the plugin-core collision (i.e. the counterpart for the current $plugin->requires) is not that rare. This new syntax will give the responsible maintainer a chance to define plugin's requirements on the code level (rather than in README only) and from both the lower limits and upper limits.
In that case, wouldn't a better solution be to introduce a syntax for defining version ranges in the dependencies? For example:
$plugin->dependencies = {
'local_something' => '>=2013111800 <2015111600'
}That's the syntax composer uses, and the code that parses it and compares it is available as it's own small library (https://packagist.org/packages/composer/semver), so it would probably be pretty easy to implement this. I'd imagine you could make it backwards compatible too, by changing the value of the ANY_VERSION constant to '*' and rewriting a 10 digit integer on-the-fly to add a greater than sign in front of it. I might try to code up a proof-of-concept for this if I get a chance.
I still think it's worth having a "conflicts" property for the other use case though, and it could use the same syntax.
I knocked together a proof-of-concept at https://github.com/moodle/moodle/compare/master...micaherne:version-ranges
It only works for plugin dependencies at the moment, not core. (Incidentally, the only changes that are really important are in lib/classes/plugin_manager.php and the new lib/classes/versioning.php class - the rest is just the library I used to get the versioning class to work.)
It's backwards-compatible (rewriting integers), but not forward-compatible, unfortunately, so the new string syntax won't work on older versions of Moodle that know nothing about it. I'm not sure how that could be worked around, unless "dependencies" was deprecated in favour of a new property - "requires" or something.
To me, the main pros of doing it this way would be:
It's just a suggestion, but I definitely think it's worth considering!
I just noticed your post elsewhere on this thread about the idea of using semantic versioning for "library" type plugins. If you're thinking of using that, that would be another good reason for adopting this syntax for dependencies, as the underlying semver library already supports it
Additional concept: https://moodle.org/mod/forum/discuss.php?d=328380
Hello,
it seems this is one more scenario that Moodle would benefit from Composer dependency manager:
https://getcomposer.org/doc/04-schema.md#conflict
Other info about people wanting to use composer (with reasoning and links to docs):
https://moodle.org/mod/forum/discuss.php?d=275466
It would be nice if we could change the version.php to a composer.json file =)
Kind regards,
Daniel
I do see it the way Richard sees it. This is all a bit negative. So perhaps like marriage it could be:
$plugin->known_impediments
and thus the developer is not 'bullied' into certifying that the plugin works with every other plugin at any version at any time in its development or release.
Currently all the existing plugin attributes are positive ones that help to understand what is needed. I think it would be far better to leave as is and just have it that when a conflict is discovered that a suitable fix / workaround is implemented in either plugin in question. Having something that 'just works' without actually thinking about it is a good thing.
Agree Gareth - if this is implemented in the end, I think managing those expectations and ensuring that users do see it David's/Tim's way will be essential - if 2 of the 4 respondents just in this thread so far, as people involved in plugin development, see that potential confusion, then how much more is that going to happen with 'ordinary' site admins?
I can see David's point about a plugin working upto a certain version of core (one example being the versions you have of Essential, where this would prevent users installing an older version on a newer core) - but I see two issues with that line of reasoning too:
1. (Minor) The plugins database already identifies what versions of core a particular plugin (or each downloadable version of that plugin) are suitable for - OK this proposal might work to prevent that user error, but seems like overkill the way it is presented at the moment.
2. (More significant) The main reason plugins become incompatible with core is because they are no longer developed. They are not designed and released to be compatible only upto a certain 'use by date' when they were published and if there is no one actively developing them, then there is no one to go back in and edit the version.php to add a 'best before'.
Perhaps Michael's suggestion of a min & max version for core requirements and identified dependencies would be a way to go - but the max version should probably be optional, or I can see developers just adding '9999999999' as the max version!
As I said - I can see Tim and David's viewpoint that my concerns were not the intended use case, or perceived to be a significant issue, but I still have that niggling feeling from a user/admin perspective, rather than a developer one, that it will lead to a level of expectations that are not intended by the proposal.
It would be great for the plugins DB to restrict download of a plugin if it did not say it was compatible with a given core version. After all we do stipulate that already in the upload process. The snag with version numbers is that they are inconsistent. So there can be overlap temporally between M2.9 stable and M3.0 beta versions.
It would be better to have:
$plugin->compatible = array(2.7, 2.8);
etc. which can be different for each branch if the developer wants. Then it would not install otherwise (plugin dependency thing).
I spend soo much time asking the same 'what version of Moodle are you running' question when looking at problems only to discover that it is an incompatible version and hence the issue. i.e. Essential has specific LESS per stable release because the Moodle core LESS and plugin style.css files change (gradebook etc.). If a developer wants a new version to be tested on one not currently available then they will make a release.
This would also give HQ and easy way of publishing a 'compatible contributed plugins' list so that people can make an informed decision and not waste time / get disappointed.
can be overlap temporally between M2.9 stable and M3.0 beta versions.
I believe that any existing and future Moodle X.Y.Z version has always the $version number lower than any X+1.*.*, X.Y+1.* or X.Y.Z+1. There is never overlap between any 2.9 and 3.0 version, for example. Even 2.9.99 would have lower version than any early 3.0 beta version. That is the result of the versioning policy to freeze the date part (first 8 digits) when the major release branch is created.
So even though there was an on-sync period, where 'technically the software was the same', then M3.0 dev had:
$version = 2015051100.03:
$release = '3.0dev (Build: 20150528)';
and currently M2.9.3+ has:
$version = 2015051103.06;
$release = '2.9.3+ (Build: 20151209)';
therefore a plugin would be deemed to work for a short while on a M3.0 version then stop.
Right. Sorry for my misunderstanding. I was referring to any released (tagged) version. You are right that in the first week of the new major release, the master branch may temporarily violate the "always upgradable" rule from backwards perspective. But the DEV version is typically bumped on the next week so we are effectively talking about the first seven days of the DEV branch life cycle. I personally do not see this as a problem. Even laws of physics, time and space did not apply in first moments after the big bang.
On the surface, I like this idea. But I agree with Richard's assessment about when plugins become incompatible. Will any plugin developer actually use this? We may be adding extra complexity that will be rarely used.
Thinking about the plugins I contribute to, I can't see adding a Moodle version conflict (impediment) other than the one already defined by "$plugin->requires", unless we were close to a new release and there was absolute certainty that there truly was a Moodle conflict. For example, if I have just added a plugin that works with 3.0, I do not know if it will work with 3.1 or not. I usually assume it would. As 3.1 gets closer to release, a conflict may be discovered.
With regards to the conflicts with other plugins, again, this seems like something other people discover - not the developer. And those people may not be able to change the developer's plugin. The developer on the other hand, likely has another issue in the plugin that should be fixed to resolve the conflict.
I don't think having these tags would harm anything, just not sure if they would get used enough.
Is there a current real example where this would help?
mike
not sure if they would get used enough
That's actually a good sign isn't it? I mean, the less such conflicts is known, the less problems admins have. What I am trying to suggest is that this might be eventually helpful in some very rare situations.
Is there a current real example where this would help?
This idea came to my mind when I was thinking about a local plugin that would serve as a provider of some functionality that could be then used/consumed by other plugins. Something distantly similar to your OpenID Connect or other plugins from that set but more like a library.
Following the semantic versioning, I would start by releasing the library plugin with version like 1.0.0 (once it reaches some level of maturity) where the first "1" represents the API version that other plugins can rely on. All other plugins (consumers) would declare their dependency on this library plugin and everybody is happy.
But we know that software evolves, external services APIs change etc. So it is reasonable to expect that one day, I would like/need to change the API provided by my plugin in non-backwards compatible way. In the $plugin->release I would call the new generation/branch of the plugin as 2.0.0. But once I release such a new version in the Plugins directory, it is automatically offered as an available update to all Moodle sites using it. Even if the update for the consumer plugins is not available yet. So admins can end up updating the library to the new 2.0.0 version which breaks everything.
I am aware that this proposal does not solve the situation of orphaned plugins when there is no maintainer who would update the version.php.
Anyway, I admit all these scenarios are pretty rare and usually there is another solution for them. Thanks everybody for your feedback!
Following the semantic versioning, I would start by releasing the library plugin with version like 1.0.0 (once it reaches some level of maturity) where the first "1" represents the API version that other plugins can rely on. All other plugins (consumers) would declare their dependency on this library plugin and everybody is happy.
