-
-
Notifications
You must be signed in to change notification settings - Fork 347
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The "homepage" field in metadata should be a strong recommendation #938
Comments
I have strong doubts any user out there clicks the forum link prior to updating their mods, if such users acctually exist I'd guess they're a very small minority. Even with a warning on startup/update I still don't think many users would check all homepages, I know I wouldn't. The best solution would probably be a unified system where every mod author out there used semver or some other system which easily distinguish breaking changes, but I find that about as plausible as users caring about reading homepages :/ As you mention users have adopted CKAN because it is easy and requires little interaction save from clicking install on chosen mods and updating them. I think this is the reason why earlier suggestions have focused on metadata fixes rather than fixes which require user interaction seeing as the latter is not something the user expects from CKAN. It makes me wonder how other packagemanagers handles this kind of situation, does this kind of problem even exist for other packagemanagers? As for setting homepages fields in the startup guides I'm not at all a fan of hardcoding anything that doesn't need hardcoding. Why should we hardcode a homepage field, nor even recommend such a thing, into .netkan files pointed towards KerbalStuff where we fetch homepage information supplied by the author? Maybe a note to add it if, and only if, no homepage information is available on kerbalstuff? |
If i ever know im going to break saves with an update i will use the semver practice of updating the major version of my mod. (eg v0.17.0 to v1.0.0). it seems that maybe CKAN could give us a flag in our config for "semver compliant" and we could manage when the user would get a warning "this update might eat your saves!" EDIT: what @Dazpoet said :) |
Fair enough, closing this since other issues address this issue better. |
I acctually really like the semver compliant field idea. Although I'd guess not many modders use nor even care about such a thing there might be many enough out there that it'd be worth considering? If CKAN keeps growing the existance of such a field might be enough to warrant interest? I think there might be other issues somewhere in the CKAN repositories dealing with semver stuff aswell. I could agree that manually updating savebreaking stuff is annoying and it wouldn't be humanly possible to properly add it to all mods the second a new version hits but we're already seeing a trend of more and more users helping out with metadata so maybe reports would at least help us point to what needs updating. I think the major problem with all solutions warning users for savebreaking changes is that if it only cover some mods users are bound to rage when they install a savebreaking update and don't get a warning. A hard question to tackle indeed! |
I don't have any clear ideas for save-breaking resolutions, it is a difficult issue, but I support changing the wording to strongly suggest people to supply us with homepages. I know that we in many cases scrape them from the metadata source, but there have been cases where they are missing, and it is an easy way to get more information about mods. Checking for the homepage tag in the bot generated .ckan files before merging would and adding it to the .netkan when it is missing would, in my opinion, be a good idea. |
Adding it directly to the guide for github and "other hosting solutions" is indeed a good idea, why pet peeve is only with kerbalstuff where we can scrape it (if it exists). Having the check on the generated .ckan files sounds like a good solution since it could save us from hardcoding unecessary things. How would this be presented to the user though? Can Jenkins (Travis?) present a commit as "we recommend you update X" rather than a hard fail (red x) in a good way since I think hard fails will be confusing to users and might send them looking for missing commas rather than considering that they should add a homepage field, or do I just have way to little trust in contributors? |
In cases where no homepage exists in the KS data, can the bots be made to generate the KS link as the homepage? |
Save-breaking modsAs mentioned in @plague006's opening, #60 is definitely the relevant issue here, and the ability to mark a change as save-breaking is something we've wanted for some time. However I don't think we can trust humans to read homepages or changelogs, and I think it would be counter-productive to expect them to. One of the reasons for the CKAN being so successful is that it means mods are no longer installed by getting a human to follow the instructions another human has written. I can think of the following as being particularly useful:
Of these two, 1. is the most elegant, and I think something which is worth pursuing, especially since KSP-AVC version files are fairly widely used. 2. is a lot harder than it looks; while we'd normally make a save backup before any CKAN transaction, a naive implementation would have us making multiple backup saves which are identical. We'd want to avoid that, and also provide both human and machine readable documents inside the saves that indicate what mods were installed at the time it was made. I can forsee lots of ways we can get this wrong (resulting in us dealing with an increased support load), although I still think automatic save versioning would be good to have. Homepage recommendationsIn a similar way to the CPAN having the CPAN Testing Service (CPANTS) assigning "kwalitee" ratings, I think we could do the same for CKAN metadata. This would ideally be a separate project, but mods which include KSP-AVC support, are auto-indexed by the NetKAN bot, and include rich metadata on things like homepages and bugtrackers can get a higher "score" than those which don't. While this doesn't have any technical impact on the network at all, it gives mod authors and metadata maintainers simple achievements to get up to "full metadata health". If we (or anyone else) were to do this, I'd try to avoid metadata health being dependent upon a particular upstream provider of metadata. We don't want to push people into using KS or github, although we almost certainly do wish to add greater support for indexing from KSP-AVC and other distributed versioning systems. |
Just want to mention that #1254 basically negates all of my qualms with missing homepages. While it's still possible to have a mod added with no way to get a homepage, it's very rare. |
#60 #837 #909 All have suggestions along the lines of "CKAN should inform users when a mod upgrade will break current saves". I agree that in a perfect world that would be a great feature, but we're not in that world. The strength of CKAN is that mod authors don't have to micromanage anything to stay up to date with the system: it's what (imo) allowed for the large adoption it received. Creating a "breaks saves" field would be incredibly burdensome to authors and/or metadata maintainers since they would have to manually check every single mod's changelogs (if documented) and forum threads/support forums (if the save break was undocumented). I don't think that's a reasonable expectation.
My proposal is that we make the "homepage" field a strong recommendation (ideally would be a require but some small libraries don't have homepages) and shift the burden to the end user. I'm not a huge fan of making users do their own work (it's one of the strengths of CKAN), but given that there's no standard whatsoever for changelogs (not even all mods have them), I think it's the best solution.
On the implementation side of things: I'm currently working on getting homepages for existing mods that currently lack them and have integrated homepages into the core steps of https://github.com/KSP-CKAN/CKAN/wiki/Adding-a-mod-to-the-CKAN
From the more technical side: Maybe if whatever bot checks metadata on CKAN's side could throw up a warning when there's no homepage set so that it can be remedied before hitting the system? And/or a warning on the user side when they first run CKAN (or when CKAN updates) that the program can't detect save-breaks and that users should check the homepages for changelogs?
As I mentioned none of this is ideal, but I think the options are:
The text was updated successfully, but these errors were encountered: