Skip to content
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

[Feature] Support HighestVersion attribute for auto epoching #7

Closed
HebaruSan opened this issue Jul 13, 2019 · 0 comments · Fixed by #102
Closed

[Feature] Support HighestVersion attribute for auto epoching #7

HebaruSan opened this issue Jul 13, 2019 · 0 comments · Fixed by #102
Labels
Enhancement New feature or request

Comments

@HebaruSan
Copy link
Member

This is an outgrowth of KSP-CKAN/CKAN#2789 (comment). I assume that the initial functionality of the queue-based bot will be identical to NetKAN-bot, so ideas for further improvements should be submitted here for better tracking.

Motivation

See KSP-CKAN/CKAN#2824. We use epochs to coerce author-created versions into a sensible ordering, but this requires a lot of manual intervention and could potentially be automated.

Suggestion

Before submitting a netkan to be inflated, scan the existing versions of that module and compare their versions to find the maximum. Send this in the HighestVersion attribute of the queue
message. Proof of concept code:

https://gist.github.com/HebaruSan/1fc031cbd97a9a1db2c7bf3c46e9894f

This runs slowly because it executes mono and ckan.exe once per version (but it does output the right answer). To make it acceptably fast, we would need to rewrite the version comparison logic in Python:

https://github.com/KSP-CKAN/CKAN/blob/14ab1522e410c2bb0860d60b8986f625ec42a78e/Core/Versioning/ModuleVersion.cs#L191-L365

Or we could write a new ckan.exe max_version a b c d command, etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant