The Qt components are from the same repo as other dependencies.
The KDE Platform was never a good fit for OBS Studio for multiple
reasons:
- Life cycle too short and misaligned with OBS Studio causing users to
get EOL notification too often.
- Third-party Qt plugins were allowed which could change Qt's behavior.
- KDE exclusives sandboxed holes were inherited.
To reduce compile time and prepare for aarch64 support, dependencies
compilation except CEF is moved to a BuildStream project junctionned
with Freedesktop SDK.
The BuildStream project is configured to build dependencies in a
Flatpak-like environment.
The current version of swift-format uses features that are only
supported in more recent Swift compiler versions than the one shipped
with Xcode 16.1.0.
When 31.0.4 was published, it published to the Flathub beta channel,
which overwrote the running 31.1.0 beta/rc. This was due to an
assumption that we would not publish an out-of-band hotfix release once
we had moved to a new beta release cycle. To prevent this in the future,
we can check the last two releases to see if they are different tag
series and if one is a prerelease.
When 31.0.4 was published, it published to the Flathub beta channel,
which overwrote the running 31.1.0 beta/rc. This was due to an
assumption that we would not publish an out-of-band hotfix release once
we had moved to a new beta release cycle. To prevent this in the future,
we can check the last two releases to see if they are different tag
series and if one is a prerelease.
Explicitly label the Windows x64 artifacts and assets as such to
disambiguate them from the Windows arm64 artifacts and assets.
Subsequently, make the windows-patches action able to take an
architecture argument which defaults to x64. This will help enable later
usage for Windows arm64.
Lastly, rearrange some of the Windows lines in push.yaml to have a
consistent order.
I discovered while investigating a separate caching issue that the read
command was not assigning ref correctly. This is inconsequential since
we do not use that value, but it led me to look up the documentation for
the GitHub CLI extension used here, gh-actions-cache.
The GitHub CLI extension gh-actions-cache is deprecated as of October
2024. The recommendation is to use the offical gh cache command. That
command produces slightly different output, so adjust the read command
accordingly.
By adding the workflow_dispatch trigger, the scheduled workflow can
also be manually triggered if the scheduled run failed to run due to
scheduling issues or because of an error that might have been fixed
since then.
actions/cache versions other than v4, v3, v4.2.0, and v3.4.0 were
deprecated and gradually sunset through February.
@actions/cache versions other than v4.0.0+ were deprecated and gradually
sunset through February.
See:
* https://github.com/actions/cache/discussions/1510
* https://github.com/actions/toolkit/discussions/1890
flathub-infra/flatpak-github-actions/flatpak-builder set its
@actions/cache dependency version to "^3.2.3" and was last updated on
July 29, 2024. As a result, its yarn.lock file specifies version
"3.2.4", which is no longer supported and does not work.
Update flathub-infra/flatpak-github-actions actions now that they have
updated their @actions/cache dependency.
Once upon a time there was the idea to enable use of Ccache for
Windows builds on CI as well, but to achieve this the project would
need to switch to clang-cl.exe as its compiler and use an additional
post-build step to generate PDBs from binaries.
Using a different compiler for continuous integration than for building
release builds defeats the purpose of CI however, so the idea was
dropped.
