Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extension compatibility API #760

Open
JDGrimes opened this issue Jan 13, 2018 · 3 comments
Open

Extension compatibility API #760

JDGrimes opened this issue Jan 13, 2018 · 3 comments
Assignees
Milestone

Comments

@JDGrimes
Copy link
Member

See #705, https://github.com/WordPoints/dependencies

We need an API to let us check the compatibility of an extension. We'll use it with information from the updates API, and also in the future from data packaged with an extension when it is installed.

The initial primary goal is just to be able to use it for #705, but to ensure it will be able to expand in the future without having to be completely rewritten.

@JDGrimes JDGrimes added this to the 2.5.0 milestone Jan 13, 2018
@JDGrimes JDGrimes self-assigned this Jan 13, 2018
@JDGrimes
Copy link
Member Author

JDGrimes commented Jan 13, 2018

Suggestions for the User

As noted in #705 (comment), when encountering an unmet requirement we'd like to give the user some direction on how to resolve it.

Basically, the API ought to encompass not just determining if an extension is compatible, but also why not, and what the user should/can do about it.

In particular, when an update for WordPoints (or the dependency in general) is available that would cause the requirement to be met, we ought to encourage the user to install that update.

E.g.:

This update is not compatible with WordPoints 2.4.0; it requires at least version 2.5.0. Please update WordPoints so that you can install this update.

However, if we are going to do that, we also ought to determine if the update is compatible.

Thus, we need the API to handle the checking of the dependencies' compatibility as well. (Which we'll need to do anyway if we want to check the compatibility of dependency updates in general, not just when suggesting them in response to a check on an extension.)

@JDGrimes
Copy link
Member Author

Priorities

When making a suggestion to the user though, there may sometimes be several possible resolutions, particularly with a large dependency web and with multiple updates available. So what should be given preference, how do we determine what we should suggest?

Of course, what ought to generally be given preference is security updates. However, I think that we will eventually want to treat them specially anyway, so that they will even be installed automatically if needed. This would of course also mean that they would have to make not changes to compatibility, etc. So they wouldn't actually factor into this equation, they'd be handled on a completely separate "track".

So leaving security aside, what should get preference? Installing as many of the updates as possible?

We should certainly only move forward, never having the user downgrade. Because once an update has occurred, the db, etc., may have been modified. So downgrading should never be suggested.

And we should prefer updating over not updating.

But when it comes to giving one or another update priority, I think that it may be left up to the user to decide that. We can only give them suggestions here, after all, we're not intending to actually decide how to resolve a compatibility issue. Telling them the why and a possible solution is enough. We can refine this further as things get more complex, but we'd also like to keep things simple if possible.

@JDGrimes
Copy link
Member Author

Usually, more priority should be given to active items, rather than inactive ones. Especially if an inactive item is already incompatible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant