How do we sensibly handle "forced" installs?

[Murdabenne]

There is no straightforward way to do this. Currently you have to specify the version and do this from the command line. When you have 35+ apps that have yet to have their metadata updated, this is pretty tedious business, having to first go into the metadata to find what exact version info you need, then to individually install each of these. It pretty much defeats the purpose of having this tool.

The GUI app already has the latest version and the KSP version available to it, so it can handle this if given an override. Here is how I propose to make it work:

1. Go to Options, have a checkbox or button there that says "Allow Forced Install". Click it.
   1a. A popup appears explaining the dangers, etc. And a warning that this is a temporary setting, and will not persist between CKAN runs. OK/Cancel are the only options
2. Got to filters, select incompatible.
   2a.The list changes to show the same thing it does now, except they have checkboxes. This is the ONLY filter that will allow the option to make checkboxes, and conversely the only time you will ever see checkboxes on the incompatibles screen.
3. Proceed as usual for installs, overriding the version checks, simply grabbing the latest version available.
4. Forced Installs show in the list as "F" (like "AD") and cannot be manipulated by CKAN other than being uninstalled.

Making the setting it non-persistent prevents someone from accidentally screwing up by leaving it on the incompatibles screen and mistakenly thinking they were on the normal screen. it is a safety measure.

This will help users when we get a bugfix (x.x.BUGFIX) KSP release and authors that have a tonne of apps arent able or are unwilling to update the KSP version, or (the most likely case) they simply haven't gotten around to it but the app works and the users want it.

This issue dovetails somewhat with the version checking issue - that might provide a way for stricter version checking to prevent outdated installs, while this would provide users the ability to override that.

[Murdabenne]

Later uses for this could be expanded to perhaps allow an app to be "pinned" to a specific version (and prevent unwanted updates from showing up - like AD, this would show as P).

Or possible using the force version install methods from the command line, wrapping it for GUI use - which I do realize opens a whole can of worms for expanding the database to track older versions of the metadata, if we want to give the user a list of previous versions from which to choose.

[sarbian]

I would just add an "ignore minor" option so a mod marked for 1.0.3 would install on 1.0.4.
Minor updates that break mods are rare and an option would allow CKAN to still be useful when we have a KSP minor patch slave.

[pjf]

This is an awesome time to be having this discussion, as we do seem to be in an age of bugfix releases that don't require mods to recompile their code. It's worth looking at some of the state of play in the current situation:

• KerbalStuff only allows a mod to indicate that it targets a single KSP release. Mods which work in 1.0.3 which also work on 1.0.4 don't have a way of signalling that on KerbalStuff itself.
• AVC .version files do allow mods to signal that they're minor-release independent, but these files are stored in the mod archive itself, which means that mod authors can't easily change them without making a new release.
• It feels like many mods in the past have required recompiles on minor releases, but that's a subjective feeling and I'm not sure how many minor releases have actually broken the functionality of previously compiled mods.

From a metadata perspective, we could have a directive for our indexer which says that instead of using exact versions, it instead treats the listed version as a minimum; so a mod targeting 1.0.3 actually targets >= 1.0.3 and < 1.1.0. That would allow installing of older mods in the same series, but would not allow 1.0 mods to be selected for 1.1. Where we turn this on is a matter for debate; I'm disinclined to enable it without mod author consultation.

I think @sarbian's suggestion of an "ignore minor" option is solid; installing a 0.90 mod on 1.0 should not be a typical use case, but installing a 1.0.3 on 1.0.4 feels reasonable¹. I think that @Murdabenne's suggestion of it being non-persistent and coming with a warning is also solid, people should never be installing a potentially incompatible release by accident.

Rather than marking incompatible versions with an 'F', I'd be more inclined to give them a different background colour. Even without a force-install option, this is useful for users who have upgraded their KSP version by signalling which mods were compiled against an older release. We should let these be upgradeable, although obviously one needs to flip the "ignore minor" option here as appropriate. In the same way if they have an obvious background colouration, then I'm happy with them appearing on the main mod screen, as it's clear that these represent potentially perilous operations.

Having said all this, I'd love to hear counter-arguments. I've been resisting a force-install option for some time, but ignoring minor releases seems to be a lot less dangerous than it once was.

---

¹ Should we allow a 1.0.4 release of a mod to install on 1.0.3? That doesn't feel right to me, but I'm not out there getting my hands dirty compiling mods themselves.

[SirDiazo]

As someone whose mods did not require recompiling for 1.0.4, I merely updated them for the version tagging, why should my "Version 1.0.4" mod not be installed on Version 1.0.3?

Especially with how quick this happened, my mods don't have a 1.0.3 version, just a 1.0.2 and 1.0.4 version.

I suppose the point I'm trying to make is what happens when KSP versions get skipped by a mod? As my mod does not have a KSP 1.0.3 version, if you disallow my mod's 1.0.4 version from installing on KSP 1.0.3, does my mod simply not show in the list when a player is using CKAN with KSP 1.0.3?

Now, I am someone who specifies the compatible version directly on the NetKan manually via PRs and all my mods are still listed as version "1.0" compatible, so I don't think this actually applies to me since any KSP version 1.0.x will get the latest version of my mods.

Really, the question being asking here is "how does CKAN define compatible with a specific KSP version". Once that question is answered you can then define how you want the version numbers and spec to work.

[Murdabenne]

Maybe we need the equivalent of the US government's GRAS label - "Generally Recognized As Safe" (food label)

This is something along the lines of @sarbian suggestion about simply ignoring minors. In other words the author believes that bug-fixes most likely will not affect the app and it can be safely applied to any minor versions from this one forward. Essentially, in the metadata, we specify a minimum bug fix version (Manor.Minor.Patch -- Possibly even build if it comes to that). This means that @SirDiazo has his problem solved too - he makes his release, marks its GRAS 1.0.2, so this version will install with no issues to 1.0.2 1.0.3, 1.0.4, 1.0.42 etc. He needs do no further changes against bugfix releases - as a bonus, he can possibly even support 1.0.0 and 1.0.1 if marked "GRAS 1.0.0". but not marked compatible to KSP 1.1.0 (mismatched minor) nor KSP 0.9.2 (mismatched major) etc. This makes the addons available very quickly after bugfix level patches, reduces author workload, but also gives an author the ability to very quickly (in CKAN terms), stop his addon from being marked current if he/she does not believe it to be compatible.

This approach has the advantage of a high probability of not breaking installs, definitely reducing author workload, and keeping the player population happier by having apps being available in CKAN instantly in the case of bugfix/hotfix increments.

It depends only on 2 things, which we depend on anyway - that the author (or a fan in the case of a fan created netckan/ckan entry) knows the addon's functionality well enough to mark it appropriately, and that Squad doesn't release bugfix level patches that fundamentally change game functions (they need to go to a more mature release model - in hindsight, with all the aerodynamic changes and functional changes, 1.0.2 should perhaps have been 1.1.0 instead)

Now how do we implement it?

1. retain current functionality - compatible is compatible, period. We can call this "strict" mode internally - the KSP version tag must match the entire KSP string. This stays as the default, because we know its the safest mode and it simply works - and no code changes needed. Full support.

2. then we have Generally Recognized As Safe "gras mode" (nice this also means "fat mode" in french, how Kerbal of us) which reads a GRAS tag in the metadata if one is present, or pretty much ignores bug/patchlevel but not major or minor if no GRAS level is present. The user assumes a higher degree of risk, but not really by much. Support is limited to simply uninstalling the addon or worse case, wipe and reinstall.

3. Permissive (relaxed or lax?) checking mode - this allows things that are tagged for "everything from this major/minor version forward" (like min=0.24) to also be included, or the ones that are not tagged for a level at all - so we get things like EVE or the Astronomer's packs that have not been specifically marked but still show up (handled the same as present cases), Support the same as GRAS since we already do handle this level of interaction.

4. YOYO mode - You're On Your Own - everything in the repo, including older specific KSP versions, ancient and broken and abandoned addons show up and are installable. This would need to be guarded the most, since we have no remedy for the player other than to wipe and reinstall. Support? There is no support. Need to be explicit about that - if something goes wrong, you fix it your self - do not bother the author, do not bother CKAN, warranty void, its all there black and white, You Lose - Good Day Sir! This mode would be the one we would have them need to go into settings to activate, and it would not persist across CKAN runs, although me may need a persistent flag to show that an app has been YOYO'd so we know if there is no need for official support.

Net effect is to implement filter functions we already have, then add functionality for checkboxes and install to them based on the "functional mode" the user has chosen - Strict, Gras, Relaxed, YOYO. Then educate authors as to the GRAS tag, then introduce the users to gras, relaxed and YOYO modes.

That will handle the version issues - and also provides "forced installs" as well (that is basically YOYO mode)

[pjf]

@Murdabenne : Your ideas are really good, and "YOYO" is pronounced in my head in Jessie Pinkman's voice, which makes it even better.

Reads a GRAS tag in the metadata if one is present, or pretty much ignores bug/patchlevel but not major or minor if no GRAS level is present.

I really like this idea. I think it hits the vast majority of our current need, and I'm going to explore it further.

Having a field in the metadata is pretty important here. It means one can write strict: always (always enforce strict mode), strict: never (always ignore the patchlevel), and strict: default (use the user's setting). I think having a this mode only ignores the patchlevel is important, it's a "safe enough" operation, although I'd still require the user to turn it on every time at least to begin with, as I'm sure we'll see some bugs come out of this that we can't anticipate.

Having said that, let's try and anticipate some bugs now. Having strict: never is likely to result in bugs similar to what we've seen in #1156, namely that we might try installing an older version of a mod because a newer version is more aware of its compatibility. I'm going to suggest that to begin with we only allow strict: always and strict: default; mod authors can always specify AVC data or explicit fields in the .netkan file if they really want to mark a mod as endlessly forward compatible within a minor revision number.

Implementation

There's also the question of how we handle this from an implementation standpoint. Module.IsCompatibleKSP method appears to be ultimately where all compatibility checks are made. Thus we could:

• Try to pass a flag to IsCompatibleKSP indicating if we're in strict mode.
• Alter the KSPVersion object we pass in to IsCompatibleKSP to be a short (1.0) rather than a long (1.0.x) object.

Passing a strict flag (which defaults to true) means we can retain the current behaviour in the core, but we can shorten our own module's version requirements when it see it set to false. It's a pain of a pain getting it down there, as we'd also need to pass the flag to our relationship resolver, and also potentially to our registry when we're asking for a list of compatible modules. We end up having to check that flag everywhere. :/

Passing a short version means we don't need to add extra flags, but we still need a bunch of logic changes. But what's more is we remove the ability for mods themselves to enforce strict mode, since they can no longer tell the actual KSP version. That's worse, so passing a flag it is.

For the most part, we can probably have a strict flag on the registry object, and it can handle passing that on to the module objects as required.

Alternatively (and @RichardLake and @dbent 's input here would be great) instead of a flag we could have an IKSPComparator interface. By default this would be the strict comparator, but the client could pass in a different comparator. That meets our immediate need of ignoring patchlevels, but also meets our future needs should we require different levels of strictness (extreme YOYO mode would have a comparator that always returns true for compatibility checks). This also fits in our plans for #1149.

The comparator is pretty straightforward, in that it needs a KSPVersion object, and a Module object, and returns if the two are "compatible". It may also require minimal code change if we use something like autofac to set our desired IKSPComparator, although we'd need the comparator to be something which can be changed during runtime. Notionally it sits on the module objects themselves (since they actually do the comparison), but would mostly be controlled from the registry object (which has the power to pass the appropriate comparator when it's inflating the modules, or set the autofac scope so it doesn't need to be passed explicitly).

Thoughts and musings very welcome. I've got my next CKAN sprint this Sunday, and this and #1160 are looking like good candidates for that if they're still open by then. :)

[Murdabenne]

Not really on topic, but an app that has YOYO mode (and even better, extreme YOYO mode) which makes it more likely to release the kraken... well it is so Kerbal we almost have to do it for that reason alone. That aside, it looks like this will address several things at the same time concerning KSP patches, mod vs KSP compatibility, consistency/sanity/insanity of installed mods, quick availability post patch, user flexibility and author workload and provide more utility with less work to both the users and the authors.

[dbent]

If I'm following the discussion correctly, the idea here is to add additional metadata to basically say "the KSP version metadata is a lie"?

I propose the following instead:

1. Add exclusive version comparisons: ksp_version_min_ex and ksp_version_max_ex. These will be strictly > and < comparison operations to complement the >= and <= that are ksp_version_min and ksp_version_max.

   Alternatively, allow ksp_version_min and ksp_version_max to take an object value of the form { "version": "x.y.z", "exclusive": true }.

   Or, my personal preference. use the abbreviated style I describe in Allow Netkan per-version overrides #1160.

2. If @SirCmpwn is willing, create a PR to add KSP version range compatibility data to Kerbal Stuff. KS is open source after all, let's take advantage. This information would also be useful to the general Kerbal Stuff audience, not just CKAN users. Hardest part I think would be figuring out the UI to present to modders.

3. Modify NetKAN to consume the version range information from Kerbal Stuff. I believe we already correctly support wildcards in .version files.

4. Modify the CKAN client to always show every mod, regardless of compatibility with the KSP version. Visually indicate the mod is incompatible. Give users the ability to ignore compatibility on a transient basis.

5. Implement @RichardLake's suggestion of allowing upgrades if it doesn't make compatibility worse, i.e. if a user is using KSP 1.0.4 and has a mod already installed that's listed as only being compatible with KSP 1.0.3 (either because KSP automatically updated or because they ignored compatibility and forced install) and a new version of that mod is released that is still only listed as compatible with KSP 1.0.3, then allow them to upgrade without any fuss.

   Basically, if they already have an incompatible version of the mod installed, allow them to upgrade to the latest version of that mod regardless of compatibility.

This should allow everything as far as I know.

Modder set strictness mode

• strict: { "ksp_version": "2.0.0" }
• gras: { "ksp_version_min": "2.0.0", "ksp_version_max_ex": "2.1.0" }
• permissive: { "ksp_version_min": "2.0.0" }
• yoyo: {}

This would either be set manually in a .ckan file, specified explicitly in a .netkan file, derived from Kerbal Stuff metadata, or calculated from .version file. If a .version file includes:

"KSP_VERSION_MAX": { "MAJOR": 2, "MINOR": 0, "PATCH": -1 }

That becomes:

{ "ksp_version_max_ex": "2.1.0" }

or

{ "ksp_version_max": { "version" :"2.1.0", "exclusive": true } }

or

{ "ksp_version": "<2.1.0" }

Likewise

"KSP_VERSION_MAX": { "MAJOR": 2, "MINOR": -1, "PATCH": -1 }

becomes:

{ "ksp_version": "<3.0.0" }

I can detail an algorithm, but it should be straightforward. Alternatively we can modify KSP-AVC to include explicit exclusive-comparison fields as well.

User set strictness mode

There isn't any, just allow the user to ignore compatibility.

Conclusion

This is certainly more work but it:

• Makes metadata more accurate.
• Provides useful information to all users of Kerbal Stuff.
• It's logically simpler; thus easier to reason about and implement programmatically, which of course means, fewer bugs and weird edge cases like @pjf describes.

[ddevault]

If you can figure out a UI for it that works (both for users and modders), then I'd merge that PR.

[dbent]

@SirCmpwn This is what I'm thinking: http://jsfiddle.net/uaxh1e47/3/

Give modders two select boxes to select min and max versions. Max versions automatically filtered based on the selected min version. Add a special option to the max select box that is always <x.y.z, where x.y.z is the next highest KSP minor version (1.1.0 currently) which would be calculated dynamically based on the most recent KSP version. By default both the selected min and max values will be the most current KSP version.

The version string to show to users would have 3 modes:

• If the min and max version are the same, just show it, i.e. what happens now.
• Else if the max version is the <x.y.z option or the max version is the highest currently released KSP version then show min+.
• Else show min-max.

The actual implementation will need one extra case: When a mod has a max version of <1.1.0, but the latest release of KSP is 1.1.0 or higher. Then it should be be min-max_compat where max_compat is the most recent KSP version before 1.1.0. If Kerbal Stuff has a well ordered list of all the KSP versions then doing that doesn't even require parsing the version numbers and doing a proper comparison.

For the API the exact values of those strings could just be provided and NetKAN can smartly parse it.

This intentionally does not allow all possible variations of versioning that could occur in a .ckan file, but it provides a simple interface and covers what I would say are the vast majority of cases.

[ddevault]

That seems fine to me.

[pjf]

If I'm following the discussion correctly, the idea here is to add additional metadata to basically say "the KSP version metadata is a lie"?

Our users have always asked for a "force install" functionality. However recently it's become more relevant because Squad has been making KSP releases which haven't broken many mods. This means that many mods don't require a recompile, which means they don't get new releases, which means that the current release metadata (on KS or KSP-AVC) don't get updated, which means that our metadata lags behind reality.

So, there are two sides of this coin:

1. We want to make it easier for the metadata to be accurate as quickly as possible. Updates to KS and providing more descriptive version conditions help here.
2. We want to give adventurous users the ability to wiggle version compatibility during the "lag period", but preferably with a high degree of safety.

More accurate metadata

Add exclusive version comparisons: ksp_version_min_ex and ksp_version_max_ex

Aye, it's clear that we need these in some form or another, so a spec change seems inevitable. I really like your syntax in #1160 as well, so I'd float something like:

• "ksp_version" : "1.0.3" - precise version
• "ksp_version" : "1.0.3+" - 1.0.3 or higher (inclusive) AND exclusively less than 1.1
• `"ksp_version" : "1.0" - any 1.0.x release, identical to "1.0.0+"
• "ksp_version" : [ ">= 1.0.3", "< 1.1" ] - As the second point above, but longhand syntax; each condition is tested and ANDed together.

I'd leave the ksp_version_min and ksp_version_max as they currently operate, but in a "supported but not encouraged for new metadata" state.

I'm unashamedly introducing a human-friendly format here ("1.0.3+") that's super-easy to reach for, and which generally does the right thing by not leaking over major release boundaries. If people are ever editing the metadata by hand, this syntax makes it easy for them to do the right thing.

Handling the lag period

Even if we make it easier for metadata maintainers and mod authors to update their metadata, we'll still have a lag period between new KSP releases and all the metadata being updated. The GRAS/Fuzzy versioning mode would effectively flip a precise version to a "plus" version, provided the metadata doesn't expressly forbid that.

The improved metadata syntax should reduce the need for users to enable GRAS/Fuzzy mode, but I don't believe it will eliminate it.

I feel the two changes compliment each other very well. We provide a way for users to try probably-compatible releases on new KSP versions in an informed way, but avoid the pitfalls and limitations of the existing ksp_version_min. A GRAS/Fuzzy mode still provides a safety net (you can't accidentally install a wildly incompatible release), rather than dropping version checks entirely (although the proposed IKSPComparator or IGameComparator would provide a reasonable method to implement both).

The RichardLake solution

Implement @RichardLake's suggestion of allowing upgrades if it doesn't make compatibility worse, i.e. if a user is using KSP 1.0.4 and has a mod already installed that's listed as only being compatible with KSP 1.0.3 (either because KSP automatically updated or because they ignored compatibility and forced install) and a new version of that mod is released that is still only listed as compatible with KSP 1.0.3, then allow them to upgrade without any fuss.

This seems solid, and I like it.

[ferram4]

Having said all this, I'd love to hear counter-arguments. I've been resisting a force-install option for some time, but ignoring minor releases seems to be a lot less dangerous than it once was.

Something worth noting here is that minor / major / patch / whatever versioning numbers for KSP version actually have little, if any, meaning behind them, and all minor version increments are not created equal. For example, 1.0.1 -> 1.0.2 and 1.0.3 -> 1.0.4 resulted in no API changes and nothing breaking; 1.0.0 -> 1.0.1 added new API options that could be required and 1.0.2 -> 1.0.3 included changes to the heating system and its API that could break some mods as if it were a major version release. There is also always the risk of something marketing-related along the lines of 0.23.0 -> 0.23.5 again, which was a major version increment in all but the actual version change.

Were Squad more consistent, this would be okay. Squad is unfortunately inconsistent enough to make this a very risky proposition.

[dbent]

Our users have always asked for a "force install" functionality. However recently it's become more relevant because Squad has been making KSP releases which haven't broken many mods. This means that many mods don't require a recompile, which means they don't get new releases, which means that the current release metadata (on KS or KSP-AVC) don't get updated, which means that our metadata lags behind reality.

Yeah, I get that, my point was more along the lines that adding additional metadata to tell CKAN how to interpret the ksp_version properties isn't really necessary, when with some minor tweaking to those properties they're expressive enough to cover all the reasonable cases.

I'm unashamedly introducing a human-friendly format here ("1.0.3+") that's super-easy to reach for, and which generally does the right thing by not leaking over major release boundaries.

Heh, I wince a little bit at the non-orthogonality but I'm the kind of person that would have never implemented ksp_version, but would have just said "Set ksp_version_min and ksp_version_max to the same value."

The improved metadata syntax should reduce the need for users to enable GRAS/Fuzzy mode, but I don't believe it will eliminate it.

A persistent setting is a 👎 from me, because that's going to be a setting users turn on once and then never turn off again. Installing a mod on a version of KSP we think it's incompatible with should at least require some amount of hurdle jumping, even if the hurdles are a foot tall. I think requiring an explicit action the first time for each mod and then using @RichardLake's suggestion, are those one foot hurdles. I honestly don't think anyone is going to see the warning and be like "Well now I have reconsidered and shall not install this incompatible version!", but at least they will have been put on notice.

Were Squad more consistent, this would be okay. Squad is unfortunately inconsistent enough to make this a very risky proposition.

Yeah, we can't really derive concrete meaningful information from the version numbers, so what we're discussing is effectively a heuristic, "What changes to the version number indicate the least likely amount of possible breakage". I hate a force-install option personally, I think giving users a way to "force" anything is effectively asking them how many bullets they want loaded in the chamber when they play russian roulette. But, users can always do what they want anyway by installing manually. At least this way we can give them appropriate notice; yes, they'll ignore it anyway, but I believe the purpose of a warning in software isn't to actually warn the user, but to give the developer an excuse to say "told you so" when something breaks.

[Hexicube]

One thing I didn't really see pointed out: If you have a more relaxed version check (say, allow all 1.0 mods) that would flag mods as potentially an issue (such as the background tinting for YOYO mode), it should still check if that mod would have actually been listed in a stricter mode that would not require such a thing, and apply the warning flags appropriate to the level of potential hazard.

No point telling the user that a 1.0.4 mod installed on 1.0.4 is a potential hazard because they had relaxed version checking turned on.

Other than that, I'm all for both allowing relaxed version checking and non-specific max versions.

[Murdabenne]

@ferram4 makes a good point, especially since he is addressing this from an author's standpoint. CKAN needs to realize that it has 2 groups it is supporting here, the first is obvious: mod users. The second is indirect but no less important: the mod authors. The users can be a source of info in terms of telling us about compatibility/incompatibility of mods, like/dislike of CKAN itself, and driving some of the interface. But I think CKAN may have overlooked the authors as a good source of input. Ultimately, they are the best judge of whether a KSP release is a big one, or of no consequence.

The question I want to ask is: how do we use the judgement/knowledge of the mod authors to better CKAN for them and for the mod users? I think one area would be in asking them for input on 3rd number releases (the X in n.n.X). Any place else they would be bugfixes and not break backward compatibility, nor change functionality, nor introduce API changes. compatibility. @ferram4, above, provides the perfect example of just how inconsistent version numbers can be from the aspect of a mod author. This is what CKAN needs to learn from the mod authors: is this latest patch a minor bugfix or is it a major (enough) change? If the author consensus is that the patch/increment is not a function change or API change, then the more permissive controls should be used. However, if the consensus is that the patch is a function/API change, then CKAN needs to apply the stricter controls for allowing versions to move beyond their current stated KSP release max.

This setting can probably be included with the master data set that is sent out in the refresh package. So the mecahnics of this, and ways to allow mod users to screw up their installs or help them avoid that are detailed pretty well in discussion here and other issues.

Now this becomes a matter of Who does CKAN ask in order to come up with a consensus. My suggestions is CKAN see which are the top used mods, and then also which are the more complex (and likely to be affected) mods that are in fairly wide use. The former would get the "tool/utility" type mods like toolbar, mechjeb, KER, StockBugFixes, the latter will get the (in my view) high impact and complex mods like FAR, KSIE, , KIS/KAS, EPL and others. Some way to get a quick poll of the minds behind those is what CKAN needs to judge whether to use strict or permissive versioning by default when presenting mods to the users. I think this will work if we can figure a fast way to get those author's opinions.

Assuming CKAN can find this out, it comes back to this question: _how do we provide individual authors, if they wish to use it, a _no-workload* way of letting CKAN know their app is GO/NOGO with the new patch* so that CKAN does not generate additional question, work or wasted time for the authors? Frankly, other than using issues here or posts/pm ont he forums, I must admit I do not have a good idea for this - perhaps the mod authors might have one?

Bottom line is that CKAN cannot ignore or neglect the impact it has on the authors, and CKAN should be teaming up with the authors to help each other.

[pjf]

I'm digging this out again for because I've a hunch that we'll see a 1.0.5 before a 1.1, and I'd like us to be ready for it both being released, and a whole lot of 1.0.4 mods being compatible with it.

So right now, I'm intending to (over the next 36 hours):

• Create an IGameComparator interface (thinking forward to when we handle more than just KSP). This means we can at least plug in different classes to handle the various proposals.
• Create an IGameComparator concrete class which says that 1.0.4 mods are compatible with 1.0.5, unless the mod has been marked as "strict".
• Report and expand on my progress here as I go.

This isn't a complete implementation of what we've discussed, but it'll certainly be in the right direction.

[cparen]

Interestingly enough, we have seen a 1.0.5 come out, been out for moths, yet KER and DMP both "work well" on 1.0.5 yet are listed in the CKAN repository as being incompatible with 1.0.5. An override button would be nice here. I'd like to point people at a CKAN config and just tell them "yeah, it will complain about DMP and KER -- just ignore and hit 'accept anyway'". Instead it halts with an error.

Thanks for your consideration.

[Olympic1]

As we mentioned multiple times on GitHub and the forums, we are not adding development versions to CKAN. As long as KER and DMP don't release stable releases, we won't add them to CKAN.

[politas]

To be more precise, we are not adding development versions from GitHub. Development releases put out anywhere else are fine. It's a bit of a double standard.

[politas]

I think the need for this has been ameliorated with #1957