[libvirt] [RFC] Version numbers outside of releases
Daniel P. Berrange
berrange at redhat.com
Thu Jun 1 12:06:42 UTC 2017
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 :|
More information about the libvir-list
mailing list