On Mon, Jan 25, 2021 at 6:41 PM Dr. David Alan Gilbert <dgilb...@redhat.com> wrote: > > * Bin Meng (bmeng...@gmail.com) wrote: > > On Mon, Jan 25, 2021 at 12:59 AM Philippe Mathieu-Daudé <f4...@amsat.org> > > wrote: > > > > > > On 1/23/21 11:40 AM, Bin Meng wrote: > > > > From: Bin Meng <bin.m...@windriver.com> > > > > > > > > With all these fixes and improvements, there is no way for the > > > > VMStateDescription to keep backward compatibility. We will have > > > > to bump up version ids. > > > > > > Unfortunately this breaks bisectability (think about downstream > > > distributions cherry-picking patches individually). > > > > > > I don't think there is a problem increasing 2 -> 3 -> 4 -> 5 > > > (Cc'ed David in case). Could you respin increasing the version > > > on each VMState change? > > > > > > > I definitely could be wrong, the reason I posted a single patch to > > upreve the version is that, I was under an impression that in each big > > release (like here 5.2.0 -> 6.0.0), the incompatibility version id > > should be bumped up once. > > It does not look correct to me that in a big release we bump up the > > version id for 10 times. > > I think I agree; I don't think we've ever done it incrementally like > that before. >
Thanks David. > It would only break bisectability if you were cross-version migrating > during the bisect which is rare. > > > Since this is a series to fix issues in the ssi-sd, I don't think it's > > practical for downstream to just cherry-pick some commits while > > leaving some other commits there. > > Never underestimate downstream :-) > However, please add a comment when you're doing incrimentals like this - > e.g. a TODO or something showing that it's unfinished and you need the > remaining patches so people don't do it accidentally. > Sure, next time :) Philippe, I guess we will need to hold on your PR? http://patchwork.ozlabs.org/project/qemu-devel/list/?series=226135 Regards, Bin