-
-
Notifications
You must be signed in to change notification settings - Fork 349
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
Handle no-op upgrades #54
Labels
Comments
This happens so rarely that I believe it's a non-issue. |
Aye. This is so meh I'm closing it. |
RichardLake
pushed a commit
to RichardLake/CKAN
that referenced
this issue
May 30, 2015
Add Serializable attribute to CKAN.Version
RichardLake
pushed a commit
to RichardLake/CKAN
that referenced
this issue
May 30, 2015
Change restart behavior when selecting another KSP instance.
RichardLake
pushed a commit
to RichardLake/CKAN
that referenced
this issue
May 30, 2015
Adds regular expressions support in Remove
This issue was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Scenario: The user has a mod installed. A new version of KSP is released. It's discovered the mod works fine on the new version, so updated metadata is released signalling its support.
An upgrade here doesn't have to do anything, but because we save the meta-data that existed at the time the module was installed, we may show it as being out-of-date when it's really not.
As part of
ckan upgrade
, it would be nice if we were able to handle these no-op upgrades and just update the stored metadata, rather than uninstalling the mod, and then reinstalling exactly the same mod. That may not be as easy as it sounds, because we'll still want to check relationships, install stanzas, and the like.Since we already cache downloaded mods, a complete reinstall to update the metadata should be fine, even if it's sub-optimal, but this would be nice to have.
The text was updated successfully, but these errors were encountered: