We're planning to ship fwupd 1.4.x in RHEL 8 and so it makes sense to have a
stable branch to do point releases. I don't intend to release versions 1.5.x
any time soon, so moderately-agressive backporting to 1_4_X is okay.
Getting the version string from git means the commit version changes each time
we commit any patch, which means we need to use --force to install firmware
when building fwupd against a version that should be compatible.
It is also very inconvenient not bumping the release version for git snapshots
as firmware can no longer depend on the "planned" release triplet.
tl;dr: A good idea for Flashrom, not so awesome for me.
This does 'bleed' the metadata contents into areas previously covered by quirks,
but in this case may be pragmatic and more up to date than a build-time
generated quirk file, which increases the user-friendliness of fwupdmgr.
The UEFI ESRT table just gives us a table of GUIDs with some basic flags, and
isn't very useful to end users. This is acceptable for Dell as there is only
typically one ESRT entry, which is for the system firmware. On typical Lenovo
hardware there might be half-a-dozen different 'Device' entries which all look
very similar.
As it's not possible to get a channel-of-data from the ODMs to fwupd, use the
existing LVFS metadata to generate some better names for these devices.
Although this looks like a lot of repeated data, libxmlb helpfully dedupes the
strings for us, making the quirk store only slightly larger.
Also, I've deliberately made this a manual step as we're not going to have
internet access on distro builders, and I'd also like the fwupd tarball output
to be deterministic and repeatable.
This is inspired by a change in flashrom to read the version string for meson
dynamically.
No need for "post release version bump", this happens automatically from git
now by there being a dirty commit.
Target to run the contrib/fix_translation.py scripts with the
correct path. Update the RELEASE documentation to use the new
target instead of calling the script "manually".
This matches what a lot of other projects do, and means we can easily format
the release notes back into NEWS format, but also into HTML and Markdown.
This also means we can show the correct update description in gnome-software
when building a flatpak, rather than falling back to the generic project
description.
