On 11/14/2017 03:35 PM, Max Reitz wrote: > On 2017-11-14 21:30, John Snow wrote: >> >> >> On 11/14/2017 01:46 PM, Max Reitz wrote: >>> On 2017-11-14 19:45, Thomas Huth wrote: >>>> On 14.11.2017 14:32, Max Reitz wrote: >>>> [...] >>>>> Well, do you want to document it? I'd rather deprecate it altogether. >>>> >>>> Maybe a first step could be to change qemu-img so that it refuses to >>>> create new qcow1 images (but still can convert them into other formats). >>>> So basically make qcow1 read-only? >>> >>> Yep, and the actual first step to that is to make it issue a deprecation >>> warning when creating qcow v1 images (which is what I proposed). :-) >>> >>> Max >>> >> >> Deprecation warning is good. >> >> In future versions you can shimmy it behind a >> --no-really-I-want-this-old-format option, I think we ought to support >> creating the images for as long as is technologically convenient. > > Well, at some point you can also demand from users to just dig out some > old version of qemu-img to convert their qcow v1 images to qcow2. It's > not like they are going to miss out on anything. >
As long is convenient. I won't throw a fit that it needs to be around forever, but as long as it's sufficiently guarded from use and isn't hard to keep around I'd prefer to do that. I suppose it's just a weak preference. > (If you deprecate emulated hardware, users may complain that they don't > get the newest qemu features/bugfixes/... while continuing to use that > hardware, so I can see that it's a tough decision whether to deprecate > that. But it's not like you are going to lose any features or anything > if you convert your dusty images to qcow2. On the contrary, we're > helping you to get more performance out of them. Maybe qemu should just > silently convert qcow v1 images to qcow2 without asking the user, like > Apple did...) > > Max > "Like Apple did" seems sufficient justification to never do that, but maybe that's just my own opinion.
