refs/tags/1.2.1 Fri Jul 12 09:24:23 2024 +0200 1.2.1
refs/tags/1.2.0 Thu Jun 27 15:31:45 2024 +0200 1.2
refs/tags/1.1.83 Tue Jun 18 12:47:40 2024 +0200 1.1.83
refs/tags/1.1.82 Fri May 24 11:48:53 2024 +0200 1.1.82 refs/tags/1.0.7 Fri May 24 11:12:36 2024 +0200 1.0.7
refs/tags/1.1.81 Thu May 16 10:25:45 2024 +0200 1.1.81
So I suspect what’s going on is those packages have certain target versions that will be stable and then pushed to Fedora 40. So when to expect or what would those versions be?
dnf5 wasn’t complete (and still isn’t) when f40 was released.
That has nothing to do with the question, dnf5 is in the official Fedora 40 repos (see below) and I know the limitations of it and prefer to use dnf5 (or at least have it installed so it’s an option to use).
dnf info --available dnf5
Name : dnf5
Epoch : 0
Version : 5.1.17
Release : 1.fc40
Architecture : x86_64
Download size : 700.6 KiB
Installed size : 1.7 MiB
Source : dnf5-5.1.17-1.fc40.src.rpm Repository : updates
Summary : Command-line package manager
URL : GitHub - rpm-software-management/dnf5: Next-generation RPM package management system
License : GPL-2.0-or-later
Description : DNF5 is a command-line package manager that automates the process of installing,
: upgrading, configuring, and removing computer programs in a consistent manner.
: It supports RPM packages, modulemd modules, and comps groups & environments.
Vendor : Fedora Project
In my opinion, if dnf5 is in the official Fedora 40 repos then it’s good enough to use or it wouldn’t be there.
The latest version of both packages are now being tested in rawhide aka Fedora41.
Again that’s not the question, I know FC41 had the newer packages for both, I mean on Fedora 40 can we expect a pipewire update to 1.2.x ? I don’t want to use the pipewire from fc41 because pipewire is an entire ecosystem of packages that are related:
all those package have version 1.0.7 in their names for a reason.
I don’t want to jury rig in “pipewire” 1.2.1 from FC41 with my existing 1.0.7 packages. I could jam all dozen of those pipewire packages from pipewire-1.2.1-2.fc41 | Build Info | koji but I’d rather not, it seems like a bunch of hacking of my system.
I wrote a bug against plasmashell with Pipewire 1.0.7 in use and would be interested to try a newer pipewire to see if it fixes the bug:
I was able to make a script to get all those packages, then I upgraded to those, did the test and showed the bug is still there. Used “dnf install ./pipewire*1.0.7*rpm” to install back to the old 1.0.7 files (I’d used the script to get all the files in the local folder)
Again, read @vgaeterapost, second post of this topic. It links to the update policy which is being implemented: no major updates within one release. Big update → next release.
Well, okay I looked at that “updates policy” but it doesn’t seem very sensible to me, Fedora 40 is on pipewire 1.0.7 and the new pipewire is 1.2.1 in Fedora 41. So that’s hardly a “big release” since they’re both in the same major version. Maybe the version numbers in pipewire to completely ad hoc and 1.0.7 to 1.2.1 is a huge change.
I went ahead and upgraded my test Fedora 40 from pipewire 1.0.7 to 1.2.1-2 and wireplumber to 0.5.5 (whatever was on Fedora FC41). I used “dnf upgrade --releasever=41 …” to full them from the FC41 repos.
They worked just fine as is but didn’t fix the Bug 486272 I reported to bugzilla.
So basically it doesn’t matter anyway and I’ll have to put up with the bug until FC41 probably fixes it. 486272 might be a quirk of AMD laptops because I have a Intel Dell that doesn’t do the weird thing with headsets as described in my bug.
Thanks
You can check out the PipeWire Releases page and look at the changes implemented between 1.0.7 and 1.2.1 to see if they would generally be considered big/major - I’d argue they are.
Keep in mind how long PipeWire was on versions beginning with 0.x, and the amount of major work that happened during that time…and keep in mind that a whole heck of a lot of software doesn’t truly follow the semantic versioning prescriptions, including the Linux kernel itself!