![]() ![]() This has the effect of preventing future users of downloading the release through CKAN when it would otherwise have worked, and makes us have to release kOS every time KSP has a release, even if all we do is update that version file in our release. The only way to avoid this problem is to become pessimistic and always assume a release is going to become incompatible immediately on the next release of KSP, and mark it accordingly. ![]() We can only change that version file in a new release of kOS, which would be compatible anyway. ![]() We can't even retroactively change kOS 1.1.3.0's stats about its compatibility with KSP 1.3.1 now without confusing CKAN even further. Usually, SQUAD doesn't break things until a more major version number increase, but there's no guarantee, so we guessed randomly that it would work up to 1.3.x, so at least CKAN wouldn't prevent downloads of a working version. We don't own a time machine, so getting this guess right is impossible. CKAN requires mod writers to randomly guess ahead of time, at the moment they make a release of their mod, which future update to KSP will be the one that breaks compatibility with that release, and mark the release accordingly in one of the files contained inside the project in THAT release of the project, at THAT moment of history in its github repo. ![]() There is a big flaw in CKAN's design about this. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |