Autogenerate spec version for modpacks #4173
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
#2971 updated the spec version for modpacks from
v1.6
tov1.18
so the license could validly be set toUnlicense
. In principle, anytime we add a new license or change anything else that might depend on the spec version, we need to bump the generated modpacks' spec version by hand. And in fact we've already missed this once, when theMPL-2.0
license was added inv1.30
.Now that we have a way to calculate spec versions automatically (see #4155), it makes sense to eliminate this as a manually maintained item.
Changes
SpecVersionTransformer.MinimumSpecVersion
is moved to a new static classSpecVersionAnalyzer
in CoreMinimumSpecVersion
accepts aCkanModule
parameter instead ofJObject
(converted withJObject.FromObject
)RegistryManager.GenerateModpack
usesSpecVersionAnalyzer.MinimumSpecVersion
to set the default spec version before it returns its moduleEditModpack.ExportModpackButton_click
usesSpecVersionAnalyzer.MinimumSpecVersion
to set the spec version after the user finishes editing and before the modpack is saved to disk