While working on pack updating, instance naming always gets in the way,
since we need both way of respecting the user's name choice, and a
standarized way of getting the original pack name / version.
This tries to circunvent such problems by abstracting away the naming
schema into it's own struct, holding both the original name / version,
and the user-defined name, so that everyone can be happy and world peace
can be achieved! (at least that's what i'd hope :c).
Signed-off-by: flow <flowlnlnln@gmail.com>
The new versioning system is based on the versioning system used by the
GNOME Foundation for the GNOME desktop.
We are dropping the "major version" as defined by SemVer and move to a
version number with a most and least significant number.
The most significant number must be incremented, if there are new
features or significant changes since last major release.
Otherwise, the least significant number must be incremented, if there
are only minor changes since the last release. New features or
significant changes mustn't be introduced by a bump of the least
significant number.
If a minor change would introduce small user-facing changes (like a
message-box or slight UI changes), it could still be classified as a
minor change.
At the end of the day, a human shall decide, if a change is minor or
significant, as there is no clear line that would separate a "minor" and
a "significant" change in a GUI-application.
Definitions:
feature: New user-facing functionality
significant change: Something that changes user-facing behavior
minor change: Something that fixes unexpected behavior
Signed-off-by: Sefa Eyeoglu <contact@scrumplex.net>
Don't update disabled mods to prevent mod duplication. Also, chop
filename in the metadata with a '.disabled'.
Signed-off-by: flow <flowlnlnln@gmail.com>
This makes the metadata generation code a lot messier and harder to use,
but there's not really much else that can be done about it while
preserving all it's capabilities :(
At least we now have speed
Signed-off-by: flow <flowlnlnln@gmail.com>
This subclasses the Review mods dialog to make a "Update review" one.
Also, all the necessary components built until now are put together in a
coherent unity that checks and generates metadata on-the-fly and checks for
mod updates, while giving and receiving feedback to the user.
Signed-off-by: flow <flowlnlnln@gmail.com>
Allows you to prompt the user for choosing a (mod) provider. This should
be fairly independent of the mod updater logic, so it can be used for
other ends later down the road :^)
Signed-off-by: flow <flowlnlnln@gmail.com>
