Am 17.07.2014 19:00, schrieb Paolo Bonzini: > Il 17/07/2014 18:47, Michael Roth ha scritto: >>> > My argument for getting this into 2.1 had been to avoid tools >>> picking up >>> > these to-be-renamed property names from the start. At this point, I'm >>> > not so sure whether it's worse to break management tools or >>> potentially >>> > some rarely used/tested option - if we decide for 2.2, is >>> backporting to >>> > 2.1.1 an option if we document it in the release notes? >> IMO, if there's some risk to breaking management or other tools, I'd >> rather it be left to major releases. And if these values are already >> misnamed >> for 2.1.0 and prior, I don't think we stop it from poliferating much >> more by >> pushing the fix up by a few months. > > I'm not sure in which case management could break (except for qom-get). > Andreas, can you explain?
I was mainly concerned about qom-set, but same goes for qom-get. The breakage would be in 2.2, if in 2.1 we introduce properties with foo_bar and rename them to foo-bar in 2.2. Since they're not in 2.0, I had asked Marcel to rename them for 2.1 on a KVM call. I checked that sPAPR is not affected, so the only issue is the trivial g_free(). Since apart from sPAPR we have a compact snippet of properties being added, grep'ing for occurrences of the old strings and verifying that the patch changes all properties should be safe for -rc3 if Peter would be willing to take a pull. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
