On Thu, Jun 01, 2017 at 02:05:04PM +0200, Andrea Bolognani wrote: > On Thu, 2017-06-01 at 12:21 +0100, Daniel P. Berrange wrote: > > This is not that attractive from POV the language bindings. > > > > eg in the Go code, I need to make usage of the new APIs > > conditional at compile time. For example for the new APIs > > added in 3.4.0 I have code like > > > > func (v *Stream) RecvFlags(p []byte, flags StreamRecvFlagsValues) (int, error) { > > if C.LIBVIR_VERSION_NUMBER < 3004000 { > > return 0, GetNotImplementedError("virStreamRecvFlags") > > } > > > > n := C.virStreamRecvFlagsCompat(v.ptr, (*C.char)(unsafe.Pointer(&p[0])), C.size_t(len(p)), C.uint(flags)) > > > > ...snip... > > } > > > > and > > > > int virStreamRecvFlagsCompat(virStreamPtr st, > > char *data, > > size_t nbytes, > > unsigned int flags) > > { > > #if LIBVIR_VERSION_NUMBER < 3004000 > > assert(0); // Caller should have checked version > > #else > > return virStreamRecvFlags(st, data, nbytes, flags); > > #endif > > } > > > > The suggested versioning scheme would require changing all these version > > numbers checks to 3003090 is rather unpleasant IMHO. > > Well, that shouldn't be needed for released versions of the > bindings as they would of course depend on a released version > of libvirt, but I see how it would make it more difficult > than necessary to develop the bindings in parallel to the new > libvirt version. > > So I guess disregard my proposal :) We should none the less fix 'make rpm' to use the best practice release numbering scheme for pre-releases Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list