I wouldn't count on it unless you add some extra repo. RHEL releases are historically behind when it comes to software, which is claimed to provide more stability, but often older kernels in RHEL simply will not support the new underlying functionality. I am hopeful that if Podman ever has to make the decision to adapt at a modern pace with new software releases, or constantly try to backport fixes and code for old software, that they'll choose the modern approach.
RHEL 8.6 upgraded podman from v3.3 to v4.0.2, so v4.2 is not outside the realm of possibility in the next release. Since podman development is driven by Red Hat, I feel that podman upgrades get quite some leeway... Very impatient to test out the play kube functionality managed by systemd.
First, some software is updated frequently in RHEL, including podman. RHEL 8 was released in 2019 and it has podman 4.0.2 from earlier this year.
Second, even software that isn't updated often, or at all, in the base system might have newer releases available as modules. For example there are recent versions of Python in RHEL 8, with just the basic runtime so that you can use pip to install more packages.
Third, the RHEL kernel is updated much more than the corresponding LTS releases. The RHEL 8 kernel is closer to 5.15-ish than to the nominal 4.18 release from which it was forked. Pace for backports has slowed down a bit, but there's interest in keeping the kernel up to date because people are running RHEL 9 containers on the RHEL 8 kernel.
Given the module streams functionality in the package system in RHEL 8+, it's fairly plausible that it would be introduced using that path.
(Currently, there are 5 'container-tools' module streams listed, with podman versions including 1.0, 1.6, 3.0, 4.0 in stable streams, and 4.0.2 in the rolling stream.)
That is fair. I don't use Red Hat anymore really and their marketing and naming around modules was just confusing at the time. They took a common component of package management called repositories and made it confusing.
