Skip minor updates

[mrixner]

• I have read the contributing guidelines, and I agree with the Code of Conduct.
• Have you checked that there aren't other open pull requests for the same changes?
• Have you tested that the committed code can be executed without errors?
• This PR is not composed of garbage changes used to farm GitHub activity to enter potential Crypto AirDrops.
  Any user suspected of farming GitHub activity with crypto purposes will get banned. Submitting broken code wastes the contributors' time, who have to spend their free time reviewing, fixing, and testing code that does not even compile breaks other features, or does not introduce any useful changes. I appreciate your understanding.

---

This PR makes the user able to skip minor updates for a package in the installation options. Minor updates are determined as the "z" portion (or "z#w" in the case of vcpkg) of two versions "x.y.z{#w}" differing. If "x" or "y" differ, it will not be counted as a minor upgrade, as well as if there aren't three parts of a version for both.

This also fixes an issue where vcpkg installation options files would use the wrong name.

Closes #2927

[marticliment]

Will check later today or tomorrow

[marticliment]

I have updated the export_version from 2 to 2.1.

I have been doing some testing, and I have found that import/export work fine, except for the case where a version 2.1 .yaml file does not load on UniGetUI 3.1.5 and lower. However .xml and .json (and .ubundle, which is internally a json) seem to work fine. To circumvent the issue, the affected yaml bundles can be easily imported on a newer version and re-exported to Json, so I wouldn't consider this a big deal. Nevertheless, I have tweaked the YAML deserialized so it ignores unknown fields (and this regression does not happen again in the future.)

I would appreciate if you could test this and confirm you are seeing the same behaviour as me

[mrixner]

I'm sorry, I'm not totally sure what you're requesting that I test. Just that skipping minor updates works, or serialization / deserialization of the install options for YAML files, or something else?

[marticliment]

Testing importing format 2.0 (old format) on this unigetui branch, and testing importing 2.1 format (new format) into UniGetUI stable (3.1.5 or lower). Opening the bundles should be enough, there is no need to install the packages, in the three formats json, xml and yaml.

Everything should work fine except opening the Yaml format 2.1 on UniGetUI stable.

I have tested it, but I don't want to risk it on such an important feature.

[mrixner]

Package bundles:

---

Import Results: (including with modified installation options that were reflected)
3.1.5 UBundle -> skip-minor-updates: ✔️*
3.1.5 JSON -> skip-minor-updates: ✔️*
3.1.5 YAML -> skip-minor-updates: ✔️
3.1.5 XML -> skip-minor-updates: ✔️
skip-minor-updates UBundle -> 3.1.5: ✔️
skip-minor-updates JSON -> 3.1.5: ✔️
skip-minor-updates YAML -> 3.1.5: ❌**
skip-minor-updates XML -> 3.1.5: ✔️

* [note: did not happen again, cannot reproduce]



It loads the packages, however doesn't show them in the list. It seemed to work until I manually changed SkipHashCheck to true, and then even changing it back resulted in this blank packages list. I restarted UniGetUI, which fixed it. I could not reproduce this, thus it's likely not an issue.

**

This is the one you were talking about, and I agree that it shouldn't matter as most people wouldn't import a newer bundle into an older version. However, if this does occur, perhaps you could give a warning that the SerializableInstallationOptions_v1 export version is older than the imported bundles and they should update (if you think it matters), and I think that's a fairly reasonable compatibility restraint. I don't know how much bundles are used but I think the really only scenario this would occur on is if someone had a bundle collection of packages they thought were useful that they shared with others who may then have an old version of UniGetUI.

Original functionality works as well.

[marticliment]

Not seeing the packages rendered is likely to be #2737

However, if this does occur, perhaps you could give a warning that the SerializableInstallationOptions_v1 export version is older than the imported bundles and they should update (if you think it matters), and I think that's a fairly reasonable compatibility restraint.

The issue here is that this will only happen on already released UniGetUI versions, so it can't really be fixed/adverted to the user.

[mrixner]

The issue here is that this will only happen on already released UniGetUI versions, so it can't really be fixed/adverted to the user.

You're right, I didn't think of that 🤦