As the title reads, a fully updated 4.2.2 system continues to show “Qubes release 4.2.2 (R4.2)” instead of R4.2.3 (cat /etc/qubes-release).
Probably qubes-release-4.2-7.noarch.rpm needs to be updated…
Thanks.
Hi @ludovic,
And thank you for explaining the situation.
When an announcement is made that a new release is available, and the announcement states that “current users of Qubes OS up to 4.2.2 need only update as usual”, I expect that it will actually work now, not in one week. Otherwise, the announcement should state “current users should see 4.2.3 in one week”.
That would make sense if the one-week delay were intentional, but it seems more like an unintended bug (i.e., someone just forgot to push it to stable). I don’t recall ever hearing that there’s supposed to be a standard, intentional one-week delay, and I’m not aware of it being mentioned in any our written policies (such as the release schedule documentation). Granted, this does seem to be happening pretty often lately, which does suggest it may be intentional.
But if it is intentional, then… why? Why not just push it to the stable repo at the same time as the new ISO is uploaded? I mean, the release date is the release date. If we want to wait an extra week, then let’s just make the release date one week later. It doesn’t really make sense to me to have different release dates for clean installations and existing installations for the same release.
I suspect one reason may be the hope that any bugs found in clean installations could be patched during that week before they affect existing installations, but that seems like a mistake. That’s what the actual testing period is for. If we want an extra week of testing, we should extend the testing period by one week, not try to trick stable users into being testers just because they happen to choose to do a clean installation instead of an in-place upgrade during that first week.