v1.0.1 contains old .version file
mheguy opened this issue · comments
.version file indicates it's v1.0.0 with ksp_ver 1.0.5
This is what happens when I release when I'm half asleep. Thanks for the catch. I can probably update the .version and release pretty quickly, is is still worth merging #2 if I do?
CKAN's indexer won't catch a new file upload on its own because it will have cached B9AnimationModules_1-0-1.zip but I poked the bot's maintainer to clear the cached file. So if https://github.com/KSP-CKAN/CKAN-meta/blob/master/B9AnimationModules/B9AnimationModules-v1.0.1.ckan says "ksp_version": "1.1.0" then you can close #2 but if it's still set to 1.0.5 then I think you should merge #2. Regardless, if you merge #2 there's no possible ill effect.
The CKAN file seems to be generating without a KSP version. Any idea why this might be? If I remove the override it generates normally.
Yeah, I derped and used both delete and override on the same field (ksp_version). Typically we replace ksp_version with a ksp_version_min and ksp_version_max.
The release of 1.1.1 adds a fun wrinkle:
A version of 1.1 is implicitly 1.1.X. We can use a min of 1.1.0 and max of 1.1.1 if you want to be safer or a strict 1.1.0 if 1.1.1 broke it.
So depending on what you want, add
"x_netkan_override": [
{
"version": "v1.0.1",
"override": {
"ksp_version": "1.1"
}
}
]
"x_netkan_override": [
{
"version": "v1.0.1",
"override": {
"ksp_version": "1.1.0"
}
}
]
"x_netkan_override": [
{
"version": "v1.0.1",
"delete": [ "ksp_version" ],
"override": {
"ksp_version_min": "1.1.0",
"ksp_version_max": "1.1.1"
}
}
]
Cache was cleared and new metadata pushed: KSP-CKAN/CKAN-meta@34cee98
I don't think there would be much benefit to me marking this as compatible with 1.1.1 at this point. The only mod that depends on it is B9, and that has a bunch of other dependencies which are out of my control (ModuleManager, SmokeScreen, RasterPropMonitor, Firespitter).