Re: [libvirt] [libvirt-go PATCH 0/3] Introduce recent DomainSnapshotXML and DomainSaveImageXML flags

On Mon, Feb 25, 2019 at 11:14:41AM +0000, Daniel P. Berrangé wrote: > On Mon, Feb 25, 2019 at 12:09:41PM +0100, Erik Skultety wrote: > > On Fri, Feb 22, 2019 at 04:43:25PM +0000, Daniel P. Berrangé wrote: > > > On Fri, Feb 22, 2019 at 04:32:27PM +0100, Erik Skultety wrote: > > > > Unfortunately, in order to support the new flags, the last patch introduces an > > > > API breakage as the convention we use for the bindings is to also enforce types > > > > for flags. > > > > > > Yes, unfortunately this need to break ABI is fallout resulting from > > > my decision to make the Go bindings do stricter enum validation that > > > we have had at the C level. > > > > How would this affect the ABI? Both the old and the new enum have the same int > > value 0x01, with the only difference that you could have fed a few more enums > > into the API even though we documented that they were unsupported for that > > usage. > > Previously an application would have done > > dom.ManagedSaveGetXMLDesc(libvirt.DOMAIN_XML_SECURE) > > With your change pushed, this becomes a compile error > > demo.go:20:27 cannot use DOMAIN_XML_SECURE (type DomainXMLFlags) as type DomainSaveImageXMLFlags in argument to dom.ManagedSaveGetXMLDesc > > because the DomainXMLFlags enum type doesn't match the new > DomainSaveImageXMLFlags enum type. Yes, but if it's a compile time error, it's static type checking, isn't that still API breakage? I'd understand if e.g. it was a public structure and the project we'd expand the structure or added padding where the type is still the same, so compilation is okay, but from binary POV it would not...