provide a "oldstable" tree or numbered ones

[ManOrs88]

would it be possible to provide an "oldstable" tree so one can keep machines updated but staying one version behind?
or provide numbered trees (only for current releases)?

that would allow to use fedora iot even when relying on third party packages or drivers, which often lag behind the release a month or two, while staying updated, which at the moments is not possible and would not be "recommendable" in some scenarios

[nullr0ute]

What do you mean by oldstable in this context? Do you mean release-1 (AKA F-41 ATM)? Or do you mean like having package X-1 in the ostree? Or do you mean having older packages available for overlay packages?

If you mean the last one you can already do it using the archive repo as done by CoreOS. We will not be enabling that by default as it's a massive security attack vector for downgrade attacks. I would be amenable to a PR to document the process with appropriate security warnings.

[ManOrs88]

I was referring to "release - 1", so one can track security updates while waiting for third party compatibility enablement

[nullr0ute]

We don't have the resources for that. In a lot of cases things like kernel and other things that would affect that follow very closely across all releases so I'm not sure that release-1 will actually provide what you're after. Can provide more details of the problems you're encountering?

[ManOrs88]

practical example would be nvidia (they always take a while to release a driver which officially supports new fedora releases) or some packages in rpmfusion,
other third party products often lag a bit before issuing a "new" package

another example could be a fleet of iot devices where you would have some devices in "devel", the majority in "stable" and some in "oldstable" for job reproducibility (for example for ci jobs)

[nullr0ute]

The release-1 wouldn't fix the nvidia problem because all the releases move to new kernels at the same time, stable releases usually around the .3 bump is the rule of thumb.

[ManOrs88]

that is true, but I'm mostly referring to their repo availability, which is rarely "timed" on a new release