Hello dear Qubes maintainers,
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.
[Edit 20240920]: Fixed by @marmarek 
Please file a bug report.
Hi @barto ,
The R4.2.3 is presently in the current-testing repository, you should wait ~1 week and it will be available in the current repository, like a normal dom0 update.
The package is qubes-release-4.2-9.fc37.noarch.rpm , so follow the below update-status:
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”.
Bug reporting process is broken, requiring too much private info to leak.
Hence, this thread.
It might be confusing, especially for new Qubes users of the stable repo.
Qubes Global Settings GUI for my being on the stable branch, next to
cat /etc/*release
also says it’s on version R4.2.2, but thanks for the info @ludovic !
It would be more user friendly if the person writing the announcement reminds about the availability on the stable repo after one week. Good to know.
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.
@marmarek, what do you think?
Forgot this one push, done.