diff --git a/RELEASECHECKLIST.md b/RELEASECHECKLIST.md
index 342c13d8db..5e6e8bccff 100644
--- a/RELEASECHECKLIST.md
+++ b/RELEASECHECKLIST.md
@@ -39,6 +39,10 @@ note where it says "(*backport*)" below if you are doing a backport.
 - [ ] Copy Github release to [Spacedock](http://spacedock.info/mod/60/kOS:%20Scriptable%20Autopilot%20System)
   - [ ] If this is a *normal release* for the most recent KSP version supported, Make sure it is set as the default (using the "changelog" link on the Spacedock page).
   - [ ] If this is a *backport*, make sure it did NOT become the default, and set the default back to the most recent non-backport version (using the "changelog" link on Spacedock).
+- [ ] NOW that all the ZIP releases are out there on the various sites, NOW go back and merge any netkan_issue_NNNN PRs into develop and into master:
+  - Any PR branches named like "netkan_issue_NNNN" are deliberately delayed until after the release ZIP file was made public in the above steps.
+  - Now that the ZIP is public, now you can merge those PR's in to both develop and master.
+  - Why? See the file called kOS.version.README_SUPER_IMPORTANT.md.
 - [ ] Update [Forum thread](https://forum.kerbalspaceprogram.com/index.php?/topic/165628-13-kos-v1130-kos-scriptable-autopilot-system/) with new change log, release date and version
 - [ ] Post update in the forum thread
 - [ ] Post update on [reddit board](http://www.reddit.com/r/kos)
diff --git a/kOS.netkan b/kOS.netkan
index 7e7562daef..a7435607e6 100644
--- a/kOS.netkan
+++ b/kOS.netkan
@@ -16,6 +16,13 @@
         "repository" : "https://github.com/KSP-KOS/KOS"
     },
     "conflicts"      :   [ { "name" : "kOS-Classic" } ],
+    "depends"        : [
+        {
+            "name" : "ClickThroughBlocker",
+            "min_version" : "0.10.0",
+            "comment" : "For better cooperation with the many other mods that use it, kOS now also uses ClickThroughBlocker to open its GUI windows.  But this means kOS won't work if ClickThroughBlocker is missing. <br/> (Geek technical note: Any implementation that tried to make this dependency optional would have involved too much expensive Reflection.)"
+        }
+    ],
     "recommends"     : [
         {
             "name": "ModuleManager",
diff --git a/kOS.netkan.README_SUPER_IMPORTANT.md b/kOS.netkan.README_SUPER_IMPORTANT.md
new file mode 100644
index 0000000000..b060e8d4c0
--- /dev/null
+++ b/kOS.netkan.README_SUPER_IMPORTANT.md
@@ -0,0 +1,73 @@
+### PLEASE TAKE NOTE IF YOU EVER EDIT kOS.netkan
+
+### IN A GIT MERGE OR PULL REQUEST.
+
+### THIS IS IMPORTANT.
+
+Do Not Ignore This Warning...
+
+Unlike how every other source code file in a project typically
+gets managed, THIS file (kOS.netkan) has a special rule that's
+different and would normally be bad practice (but we have to
+do it this way for CKAN to work right):
+
+**If you don't follow what this README says, CKAN's crawler bot
+will be populated with wrong information the CKAN people will
+have to manually fix.**
+
+#### For people making a pull request that edits kOS.netkan:
+
+This warning is for people who are thinking along these lines:
+
+*"I am writing a Pull Request that makes calls into the API of this
+other mod.  So, I think that means I should make this PR contain
+an edit to kOS.netkan to describe that mod dependency, right?"*.
+
+**Do Not DO THAT**.
+
+*Do Not Put The Edit Of kOS.netkan In That Same Pull Request, even
+though that would normally seem to be correct good practice.*
+
+**Put it in a separate pull request of its own, and name
+that branch something matching the pattern "netkan_issue_NNNN".**
+
+You can make note of it in the original pull request, but keep it
+separate so it can be merged independantly.
+
+#### For people who are reviewing a pull request that edits kOS.netkan:
+
+Read the above section first about how to make a pull request like this.
+
+Make sure you never merge an edit to kOS.version that's in the same PR
+as other code edits.  That should be grounds for rejecting a pull request
+during review and asking it to be changed to follow this rule (move
+the kOS.version edit to its own separate PR.)
+
+**NEVER MERGE THE kOS.version PR's until much later, as part of making
+the next release.  (Do it AFTER the ZIP is uploaded to the releases page.)**
+
+The order of events NEEDS to be this or else CKAN's crawler bot will
+get things wrong:
+
+FIRST, we make a new release and gets it on the github releases page,
+with the ZIP file uploaded for the release.
+
+SECOND, we edit the kOS.version file in the master branch, only AFTER
+that new release ZIP exists on the releases page.
+
+### Why?
+
+Because CKAN's crawler bot wakes up every half hour and *assumes* the
+kOS.version file it sees in the master branch goes with the most recent
+release ZIP file it sees in the releases page.  If you update the
+file on the master branch FIRST, when you copy develop over to master,
+Before you've cut the new release, then it falsely assumes the settings
+in that kOS version file go with the previous kOS release.  (i.e. if you
+add a new dependency, it will falsely associate that dependency with the
+previous release of kOS, even though that's incorrect.)
+
+The only sure way to prevent this is to make sure you didn't update
+kOS.version in master until after a release ZIP was made.  That's
+why any PRs to change the kOS.version must wait until after the release
+ZIP got put there for the CKAN bot to see.
+