Release v5.1.0

This release adds more customizability of the DNF conf through the mixer
command line, adds a --clean option and does not wipe the outputdir by default
when re-running a 'build' command for the same build number, switches to zstd
compression for delta packs, and adds misc fixes to internal code structure.

Release v5.0.2

This release fixes several bugs dealing with running in a docker
container, and provides better warnings/error messages when the
environment and conf are not setup correctly.

Release v5.0.1

This release fixes issues with setting up the new mixer.state file. The
file now correctly transfers over the FORMAT version from the builder.conf,
falling back to the system /usr/share/defaults/swupd/format, and only then
defaulting to "1".
Deletes now persist in manifests over minversions. The only time they should
be removed is when performing a format bump.

Release v5.0.0

This release introduces major changes to the way Mixer is called and
run. Previously, mixer gained support for automatically building format
bumps, but was disabled by default (with --native=true always turned
on). The flag forces mixer to run natively on the system, and not
perform format bump builds automatically. With this release, the default
becomes --native=false, meaning all mixer 'build' commands will run in a
docker container. Running in a container ensures the proper version of
the tooling is run for specific build versions, because one version of
tooling cannot build for 2 different formats.

Mixer will automatically pull the appoproriate container that can create
builds for a given format, so the format bump process can truly be
automated and correct. It will still use a container for regular,
non-format bump builds for consistency.

Note that aside from the initial docker pull,
creating a mix will not be any slower than running natively, and allows
users to build versions that require tooling outside of their
host system version.

Another significant change involves the configuration for Mixer. The
builder.conf is now updated to be a stable, relatively unchanging
config to describe your workspace. The stateful items (versions, format,
etc) are moved into a mixer.state file which holds ephemeral values that
are changed build-to-build. This keeps all stateless and stateful items
centralized and follows a single format (TOML). The new format is used
by default, but can be overridden by setting --new-config=false during
the init phase. Both configs are versioned so mixer can easily detect
format changes and config errors.

Release 4.7.0

This release enables parallel manifest creation in parts of swupd during
build update.

Release v4.6.7

This release updates mixer to build slim packs across minversions, reducing the
pack download size for clients and saving space on our infrastructure. Mixer
also properly avoids making a network connection except for commands that
absolutely need it.

Release v4.6.6

This release includes fixes to place the <bundle>-extra-files into a persistent
location, which will automatically inject listed files into a mix, reducing
manual intervention by mixer users when building a mix with unconventional
or files that are not part of any bundle by default.
Bsdiff error output is more standard and consistent, displaying the
proper delta information to make debugging failing cases easier.

Release v4.6.5

This release sets a timeout for delta creation time to 1 minute, in an effort
to skip deltas which typically end up being too large to use for packs anyway

Release v4.6.3

This release fixes mixer to not exit when upstreamurl is not found, and
to attempt to use the given format in the builder.conf. For some cases,
the mixer user may in fact be "upstream" so it does not make sense to check
upstream format compatibility.
A new tool is available called swupd-inspector, which contains various
commands that help read data of a swupd repository: download the fullfile for
a specific file, see the Manifest for a specific version, see the differences
between two versions.

Release v4.6.2

This release further parallelizes the delta creation code to do some
more complex breakup of tasks. Typically users create multiple versions
back of deltas. While each version ran massively parallel delta jobs,
each version itself ran one after another synchronously. This began to
cause problems when certain files took several minutes to complete,
because the next version could not start until the previous finished,
compounding the runtime by the number of versions back * long file.
Now, the code check if it can run a thread for each version, and then
splits up threads within those version pools so when the large file is
hit, all versions run at the same time, capping it to 1 long file run.