KSPArchipelago: suggest KerbalKonstructs and index experimental builds

[nickdavies]

• https://github.com/nickdavies/Archipelago

Summary

• Add suggests: KerbalKonstructs for all builds
• Add an x_netkan_override keyed on version: '>=999' that sets release_status: testing for experimental builds.

Tagging convention

Experimental builds are tagged v999.0.0-experimental.<N> on GitHub and marked as prereleases. The 999 major sorts above any plausible stable version under CKAN's comparator, so the >=999 constraint reliably catches every experimental without needing a NetKAN PR per release. Stable releases (v0.1.0+) fall outside the range and are unaffected.

[nickdavies]

I still need to get my tags/releases sorted out in my repo before this is ready to review/merge

[HebaruSan]

Hi @nickdavies, thanks for the update.

May I ask: Why wouldn't you just mark the pre-release as a pre-release on GitHub? This x_netkan_override mechanism looks awkward and potentially error prone.

[nickdavies]

My logic was that I wanted to use this for my long-lived experimental branch that will eventually become my next big release.

I also use pre-release for a release that I am still testing. So I will put up say 0.4.0 today in pre-release while I go and test it out myself once it looks good I mark it as latest stable.

In parallel I have some highly experimental and broken features on my 999.x.y-experimental branch. This branch so far has lived for multiple weeks before eventually making it to mainline and a new one starting for the next big unstable feature.

this seemed nice because a user could select "Testing" as their branch in CKAN and they get upgraded to 999 and then when they switch back it downgrades for them to the latest stable.

If there is a cleaner system for doing this kind of long-lived experimental branches I am happy to use that instead but this felt like a bit of awkwardness on my side publishing for a pretty nice UX for people testing out my mod.

[HebaruSan]

OK, thanks for the response.

this seemed nice because a user could select "Testing" as their branch in CKAN and they get upgraded to 999 and then when they switch back it downgrades for them to the latest stable.

The potential issue with that is that since all of those experimental builds always have a larger version number than all the stable builds, you would have to make sure there's always a fresh experimental build, forever. If at some point you decide to stop releasing them and only release stable builds thenceforth (this is pretty common in general as a mod's code stabilizes), then you'd have an accumulated collection of increasingly old "999.*" builds that users would get if they opted in to pre-releases.

We just saw something similar with Kopernicus; a Kopernicus_BE ("Bleeding Edge") metadata repo was added a few years ago for test builds in KSP-CKAN/CKAN-meta#2159. When those stopped being generated 22 months ago, users who opted in to that repo thinking they would get "bleeding edge" builds instead got some old, out of date test builds. We fixed that in KSP-CKAN/CKAN-meta#3409 by removing that repo from the known repos list, but if those builds had been in the main repo, and if their version numbers were out-of-order from the stable builds, there wouldn't have been a good solution other than deleting the metadata for those builds, which has the downside of leaving any users who had installed them without an automated way to get back onto the mainline upgrade path.

I'm not opposed to trying this arrangement, but I want to make sure you recognize and are OK with the potential downsides first.