Don't stage if compatible with current game version #3031
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Background
As of #2970 we stage modules into CKAN-meta for manual review/merge when their netkans include
ksp_version_*
properties, since these may have changed since the last release and should be manually verified.Motivation
There's a case where this isn't necessary: When the netkan is already hard coded to be compatible with the current latest game version. If the current latest game version is 1.9.1, and your
ksp_version
orksp_version_min
orksp_version_max
properties only reference 1.9.1, then any new release is going to be a bug fix release for the same game version.Examples in which 1.9.1 was the latest game version:
The author isn't going to change the compatibility to some future or past game version if the previous release was already compatible with the latest game version.
Changes
Now netkan will check whether the hard coded versions include the current latest game version at time of inflation. If so, then the metadata is already up to date, and we will not enable staging. Note that this is done on a property-by-property basis rather than combining the min/max properties into ranges for comparison, because we want to be cautious and only skip staging when we're sure it isn't needed.
Examples of metadata that will stage (assuming current game version is 1.9.1):
Examples of metadata that will NOT stage (assuming current game version is 1.9.1):
Note that there is one case in which a hard coded version range can be compatible with the current version but we will still stage: if
ksp_version_min
is a past version andksp_version_max
is a future version. This behavior is by design, because that's silly and should be examined more closely.