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

Allow older versions of plugins to be installed #898

Open
karaggeorge opened this issue Jul 21, 2020 · 2 comments
Open

Allow older versions of plugins to be installed #898

karaggeorge opened this issue Jul 21, 2020 · 2 comments

Comments

@karaggeorge
Copy link
Member

Not sure if this will be useful, but now that we have kap.version and kap.macosVersion restrictions, publishing a new version of a plugin, with new limits, means that the plugin becomes unusable for older Kap/macOS versions.

Should we explore allowing to filter through older versions of the plugin, finding one that satisfies the above two and installing that (instead of making everything latest in the package.json).

If a plugin author wants a plugin version to not be installable at all, they can deprecate it.

For the kap.version:

As we keep adding more plugin api capabilities, a plugin needs to require a higher Kap version to ensure that those apis will be there, so people on previous versions can't install them any more. Also, if I want to publish a new version of a plugin using a new api that is in a PR for example, or hasn't been released yet, I have to wait until Kap is released and then publish it, or it will be marked as not-installable by all current users.

For the kap.macosVersion:

If you re-implement a plugin to work better for a new macOS with new APIs, it doesn't mean that the old version doesn't still work for older OSes. So users stuck on older versions should still be allowed to use the older version of the plugin.

Implementation:

We can check the latest version like we do now, and if it doesn't satisfy the requirements, we can use a small lambda to go back versions (in order newest to oldest) and check the requirements (pulling package.json). The lambda can take package name and kap/macos version, and cache the result, so we're not computing it every time.

UI-wise, we can show some kind of tooltip that says you are using an older version of the plugin, and if it's because of kap.version suggest they update.

Then we'd also have to check when Kap is updated if we can bump any plugin versions and update their versions, probably on startup, maybe showing a notification for the ones that were update in case there's new options

I haven't come across this as a huge issue yet. I think personally I'm going to hit the macOS one if I'm stuck in Mojave for a while. The only part that would help me right now is that I would be able to publish new plugin releases before the new apis are released without having to wait.

Wanted to see what other people think about this.

@sindresorhus
Copy link
Member

Seems like a lot of trouble for not that much gain. Most plugins will not have a macOS version requirement. And those that do, do we even want users to be able to install old potentially broken plugins that cannot be updated?

@karaggeorge
Copy link
Member Author

Yeah my biggest concern was the effort vs gain of this.

I mostly see it for kap.version and different plugin api versions. Like you said I don't think we even have one plugin using macosVersion yet.

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

2 participants