[Feature]: easier distribution for pre-release versions of mods

[JonnyOThan]

Motivation

I often put out a pre-release version of mods like RasterPropMonitor and FreeIva and have people alpha-test them for a bit to screen for any new bugs before pushing a wider distribution. These currently always have to be manually installed since CKAN doesn't pick them up. It would be nice to make that process a little more streamlined.

Suggestions

I'd like to explore a way for mod developers to be able to publish pre-release versions of their mods and have users opt-in to receiving them.

I think in the past this has been done by adding metadata repos (for kopernicus?). This works but feels pretty clunky - and requires a lot of extra work on behalf of the modder to set up.

There are two components that I'd like to see in some kind of system:

• a way for modders to mark releases as "pre-release" vs "stable"
• a way for CKAN users to opt-in to getting pre-release versions of mods, either:
  • manually from the mod's versions tab
  • on an opt-in basis per mod (e.g. as a label)
  • globally (worst option, but I'd take it if the above aren't possible)

The modder's side of this sort of already exists, at least on github: releases can be marked as pre-release and ckan does not index these. There is a release_status field in the .ckan metadata - is this actually used for anything currently? As a weak proposal, what if we indexed github prereleases and set their release_status field? And then the decision to update or not would be on the client side.

[JonnyOThan]

Sure. Specifically I often put out a pre-release version of mods like RasterPropMonitor and FreeIva and have people alpha-test them for a bit to screen for any new bugs before pushing a wider distribution. These currently always have to be manually installed since CKAN doesn't pick them up. It would be nice to make that process a little more streamlined.

[SofieBrink]

Hey @JonnyOThan, is there a repo that currently has a prerelease? I have some scratch code going that I'd like to test against the real world.

There’s boring crew services here, but it currently only has pre-releases and is not yet ckan indexed. It does have an internal .ckan if that helps.

[JonnyOThan]

@HebaruSan Here ya go, hot off the github workflows: https://github.com/FirstPersonKSP/FreeIva/releases/tag/0.2.20.0

[HebaruSan]

The modder's side of this sort of already exists, at least on github: releases can be marked as pre-release and ckan does not index these. There is a release_status field in the .ckan metadata - is this actually used for anything currently? As a weak proposal, what if we indexed github prereleases and set their release_status field? And then the decision to update or not would be on the client side.

I have a prototype of this mostly completed in a local branch; instead of skipping prereleases, it inflates them and sets release_status: testing. (In the meantime, all usage of release_status has already been purged from the existing metadata.) Then a new setting defaults to stable and lets the user opt in to testing or development if they wish; seeking UI/UX/wording feedback on the new field in the lower right:

But there's a catch: since the old client has no special handling for release_status whatsoever, if we start indexing prereleases, only the newer client (dev builds, initially, until we make a new full release) would ever hide them! For people with the old client, pre-releases would start showing up in the normal feed of mod versions and would be installed when the user requested that mod, to satisfy dependencies, etc. with no opt-in step ever occurring. This would flagrantly violate the established expectations of mod authors across the board that CKAN doesn't index pre-releases and that therefore they can put riskier changes in a pre-release without affecting most users.

One option for addressing this is spec_version; if release_status is set, we could set the spec_version to v1.36 to hide prereleases from current clients (and unfortunately also even from dev builds due to how spec versions currently work) until the next release. But this feels weird given the history of release_status being a longstanding field that did nothing but that some people were aware of nonetheless. Or we could put prerelease metadata in a separate repo, but that strongly resembles the status quo upon which we're trying to improve.

[HebaruSan]

I mocked up some prereleases in my local metadata, and it works, but I'm not sure about the UI (ignore the weird foreground colors, I'll look into those later):

Any suggestions on how to indicate which versions are not shown as installable because they're prereleases (the top two rows, in this case)? I've thought of these options, which I don't love:

• A new column - Would take up a lot of space for something that's probably a rare corner case
• Some marker in an existing column - easy to confuse with actual versions, not a lot of space to fit something comprehensible
• Italics - Kind of non-obvious and would have to extend the legend section a bit, still probably my favorite option so far

Regardless of how that works out, we have plenty of space to explain it in the popup if they click one of those checkboxes:

[HebaruSan]

Here's what it would look like with italics for prereleases:

[SofieBrink]

How about a new row colour & italics, that’d make it more obvious and force the user to check what the version they’re installing in the legend above, maybe purple/pinkish or something?

side note, how does one differentiate between testing and bleeding edge as a modder?

[HebaruSan]

side note, how does one differentiate between testing and bleeding edge as a modder?

I don't know, I didn't create these categories, and the ones who did didn't document a definition that I've been able to find, and sometimes used them interchangeably: #403 (comment)

I guess I would start by taking them literally:

• testing: A prerelease with some less stable changes for a mostly stable existing mod
• development: A brand new mod that isn't ready for wide distribution yet

But ultimately they'll be defined functionally: pick "testing" if you want it to be installed for users who chose testing or development for the setting, and choose development if you only want it to be installed for those who chose development.

[HebaruSan]

Apparently testing was added when alpha and beta were removed.

https://github.com/KSP-CKAN/CKAN/blob/3a311bb1c121131c4297f932e8b69807aa791dfb/Spec.md#release_status

[HebaruSan]

How about a new row colour & italics, that’d make it more obvious and force the user to check what the version they’re installing in the legend above, maybe purple/pinkish or something?

I don't hate it (this is LightCoral, the bgcolor for conflicts in recommendations and the changeset):

[HebaruSan]

Think I can get away with moving the legend to the bottom? It has always kind of annoyed me that it's right up top where your eye can't skip over it no matter how many times you've already seen it before:

[HebaruSan]

• on an opt-in basis per mod (e.g. as a label)

I assume this would need to be not just mod-specific, but also instance-specific? I.e., e.g., this is the game instance where I use pre-releases of ... FARc, and in other instances I use the stable release?

[SofieBrink]

side note, how does one differentiate between testing and bleeding edge as a modder?
…
But ultimately they'll be defined functionally: pick "testing" if you want it to be installed for users who chose testing or development for the setting, and choose development if you only want it to be installed for those who chose development.

Right but how do i do this, because github doesn’t specify different types of pre-releases.
Does this then mean i need to edit my internal .ckan file for all releases to tell ckan what to do with this pre-release?
Or worse, if my mod doesn’t have an internal ckan, manually update the netkan?

I don’t personally see a point in having 2 “less-than-stable” options, especially if it’ll require the sorts of shenanigans mentioned above.
I feel like it’ll probably be a bit confusing for users too,
If i read “development - bleeding edge” to me that doesn’t sound like a pre-release. It sounds like you’re downloading a commit, which is something ckan doesn’t and probably shouldn’t support.

[SofieBrink]

As for the colour and moving of the legend, i think those both look good.

[HebaruSan]

Right but how do i do this, because github doesn’t specify different types of pre-releases. Does this then mean i need to edit my internal .ckan file for all releases to tell ckan what to do with this pre-release? Or worse, if my mod doesn’t have an internal ckan, manually update the netkan?

Oh, I misunderstood what you were asking. Yes, in the code that I have in progress, pre-releases would be set to testing automatically, and if you wanted to mark a mod even more unstable than that, you'd do it in the netkan or internal ckan. You've called that "worse", but why?

I don’t personally see a point in having 2 “less-than-stable” options,

Well, 2 options already exist. Our job is to figure out what to do with them. If you don't see any way to do that, then that's fine, you don't have to help with that part.

If i read “development - bleeding edge” to me that doesn’t sound like a pre-release.

Right, it's not a pre-release. Pre-releases would be testing, not development.

It sounds like you’re downloading a commit, which is something ckan doesn’t and probably shouldn’t support.

Yeah, I'm not married to the existing text. Suggestions welcome!

[SofieBrink]

Oh, I misunderstood what you were asking. Yes, in the code that I have in progress, pre-releases would be set to testing automatically, and if you wanted to mark a mod even more unstable than that, you'd do it in the netkan or internal ckan. You've called that "worse", but why?

I see, that’s great!
I was under the impression that for each pre-release I made i’d have to manually specify the stability to be “Testing” before then having to put it back to “Stable” for a full release. And under that assumption not having an internal ckan would make that much worse by having to submit a new pr to the netkan repo each time you make a new pre-release or release.
All that can be ignored though as it’s not what is actually happening.

Well, 2 options already exist. Our job is to figure out what to do with them. If you don't see any way to do that, then that's fine, you don't have to help with that part.

As for this part, sure i don’t have to help. I’m just pointing out (and perhaps questioning) what the use of the development is. To me now with this added context it sounds like it’ll never be assigned automatically and only be assigned by a modder.

For the other 3 parts about the text around the “Development” label already existing, and suggestions for it being welcome. I guess i’m just trying to understand why it exists in the first place. You say:

Well, 2 options already exist. Our job is to figure out what to do with them

Is this something that you’re unwilling to change? I feel like conforming to pre-existing types, even when they might not make sense is a little strange, but I’m open to having my mind changed on that if there’s a good argument for it!

[JonnyOThan]

I’d really suggest not using coral/red for prerelease versions. It looks too much like a conflict. Yellow or orange would probably be better.

[SofieBrink]

These are barely noticeable to me, (though that’s probably related to my night shift settings) i’d still like to see what a magenta or something similar would look like.
To me it feels like a pre-release should stand out, which yellow just doesn’t really do for me.

[JonnyOThan]

I like yellow and orange, magenta is also fine.

[HebaruSan]

I think I like Gold for now, it's kind of in between yellow and orange, visually distinct without being overly garish.

Adding the stability setting as a per-mod override at the bottom (I'm telling the dropdown to be wider and it's not obeying, just ignore that for now):

[HebaruSan]

What about SpaceDock? I currently have three hard coded substrings ("alpha", "beta", "pre") which, if found in the version string of a release on SpaceDock (case insensitive), would cause those versions to be marked as testing just like a pre-release on GitHub. Do we like that idea? Any suggestions for better approaches?

[SofieBrink]

I'm personally of the opinion that pre-releases aren't supposed to be on spacedock at all.
But i understand that CKAN probably wants to support it regardless. In which case i don't have any real objections to your proposed solution, assuming you do check that the characters surrounding that string are some kind of seperator type: , - etc. to prevent accidentally matching mods such as AlphaMensaes_Modular_Launch_Pads-2.7.0.zip and possibly others.

[HebaruSan]

AlphaMensaes_Modular_Launch_Pads-2.7.0.zip

No problems in that case, none of the strings would match 2.7.0.

[HebaruSan]

Testing it out on Windows, at first I thought Gold looked different, but maybe it's just that the background is different, since it's still partway between yellow and orange: