Trivial linter fis

KSP-CKAN · Jun 8, 2024 · 0dbbc2d · 0dbbc2d
1 parent f7a15e8
commit 0dbbc2d
Show file tree

Hide file tree

Showing 2 changed files with 2 additions and 3 deletions.
diff --git a/GUI/Dialogs/CompatibleGameVersionsDialog.cs b/GUI/Dialogs/CompatibleGameVersionsDialog.cs
@@ -1,6 +1,5 @@
 using System;
 using System.Linq;
-using System.IO;
 using System.ComponentModel;
 using System.Windows.Forms;
 using System.Collections.Generic;

diff --git a/policy/version-comparison.md b/policy/version-comparison.md
@@ -10,7 +10,7 @@ So, why can't we change how we do version comparisons?
 
 We index more than 700 mods, and have more than 2,500 releases indexed. Of those, we've only had a fraction where the Debian versioning spec has not worked. Changing the versioning implementation runs a very real risk of breaking existing mods, and nobody seems to submit the changes along with a proof that all 2,500+ existing documents won't be adversely affected.
 
-## It's almost never needed.
+## It's almost never needed
 
 The netkan pre-processor now has additional options for post-processing of versions into standard forms, or bumping the epoch when versions are truly wacky. These come with no risk of breaking existing mods, because we can simply apply them as-needed. In particular, we have:
 
@@ -22,7 +22,7 @@ OMG, a mod went backwards in its order (it's happened), named a version after wh
 
 Seriously. Adjusting how we generate metadata for a couple of mods means we're backwards compatible with all extant clients, and comes with a *much* smaller risk profile.
 
-## Changing versioning schemes is much harder than everyone seems to think.
+## Changing versioning schemes is much harder than everyone seems to think
 
 If we spot a document implementing the old existing spec (v1.6 at time of writing), then we should use the current versioning scheme. If we spot a document with the "new" spec (whatever it is you propose), then we should use the new versioning scheme. Holy fark, does that mean we need *two* implementations of the versioning scheme in clients? Yes, it does. Does that make things twice as complex as it currently is? You bet! Does that mean we're likely to see MORE bugs reported? I think so! And what happens when we need to compare an old version to a new version? We cry, that's what.