Hi, >>> However, unlike PC, I'd like to do linear versioning and avoid bumping >>> at every release. >>> >>> IOW, spapr-1, spapr-2, spapr-3, etc. >>> >>> I think virt ought to try to do the same. >> >> Any particular reason why ? I kind of like the clarity of having the >> version match the release version. Avoids needing to lookup a magic >> decoder ring to figure out which QEMU version maps to which machine >> version. +1, /me likes the version-based naming too. It's also easier to handle on source code level as it makes it easier to reuse the #defines we already have for pc compat properties. > (1) reduces testing matrix by having fewer versions I doubt that is going to fly. It's not like we do new pc-* machine types just for the snake of creating them, there is no policy we have to have a new one for each release. Usually we create them in case there is an actual need, i.e. a incompatible change which needs a compat property. Which so far was the case for (almost?) every release. > (2) makes people > think more carefully about whether it's really necessary to break > compatibility. Often it's not about incompatibilities but about new features which we wanna have enabled by default. cheers, Gerd _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
