Fedora’s decision concerns an additional set of optimized packages. It does not remove support for older x86-64 processors, and it does not guarantee that the proposal will ship in Fedora 46.
The decision is in the ticket, not the draft release notes
FESCo issue 3599 records rejection for Fedora 45 on August 17, with five supporting votes and no opposing votes or abstentions. The owners were encouraged to resubmit for Fedora 46 after providing performance comparisons, infrastructure impact analysis and details for installation media.
The change proposal still contains draft release-note wording describing automatic selection of v3 packages. That describes the proposed end state, not an approved shipping feature. The original story incorrectly located the decision on Tuesday and treated the eventual direction as settled.
An extra build target is not a new universal minimum
The proposal would retain existing x86-64 builds and add v3 builds, with package-management selection based on compatible CPU features. Build tools, repository handling and image composition all need to agree on that choice.
Hardware purchase year is a poor compatibility test. What matters is the complete feature set exposed to the running system. A virtual machine may see a restricted CPU model even when its host supports newer instructions. A package image selected on one host may later run on another, so migration and recovery targets belong in the compatibility assessment too.
Measure the part that actually changes
Some performance-critical libraries already select optimized implementations at runtime. Rebuilding their surrounding packages for v3 does not prove that an already optimized hot path becomes faster again. Conversely, a compiler can sometimes improve code that had no separate runtime-dispatched implementation.
An original example makes the limitation concrete. Suppose a job takes 100 seconds: 30 in affected computation and 70 in unchanged work. Halving the affected part yields 15 + 70 = 85 seconds, a 15% reduction in total time. It does not make the application twice as fast. These are hypothetical values, not Fedora benchmarks.
Compare the same source, compiler version, optimization settings and workload while varying the target level. Record correctness, elapsed time and variability, then assess the build, storage and testing costs of distributing another package set. Until a revised proposal is approved and delivered, administrators should follow the actual Fedora release requirements rather than change a fleet based on draft notes.
Correct August 17 ticket vote date, distinguish optional v3 builds from baseline removal and F46 guarantee; focus on runtime dispatch and VM feature exposure.