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

Don't stage if compatible with current game version #3031

Merged
merged 1 commit into from
Apr 21, 2020

Conversation

HebaruSan
Copy link
Member

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 or ksp_version_min or ksp_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):

    "ksp_version": "1.7",
    "ksp_version": "1.9.0",
    "ksp_version_min": "1.4.0",
    "ksp_version_max": "1.99.99",

Examples of metadata that will NOT stage (assuming current game version is 1.9.1):

    "ksp_version": "1.9.1",
    "ksp_version": "1.9",
    "ksp_version_min": "1.9.1",
    "ksp_version_min": "1.9",
    "ksp_version_max": "1.9.1",
    "ksp_version_max": "1.9",

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 and ksp_version_max is a future version. This behavior is by design, because that's silly and should be examined more closely.

@HebaruSan HebaruSan added Enhancement New features or functionality Easy This is easy to fix Pull request Netkan Issues affecting the netkan data labels Apr 8, 2020
@HebaruSan HebaruSan requested a review from DasSkelett April 8, 2020 23:35
Copy link
Member

@DasSkelett DasSkelett left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, makes sense

@HebaruSan HebaruSan merged commit ab64a66 into KSP-CKAN:master Apr 21, 2020
@HebaruSan HebaruSan deleted the feature/dont-stage-cur-compat branch April 24, 2020 19:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Easy This is easy to fix Enhancement New features or functionality Netkan Issues affecting the netkan data
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants