[libvirt] [dbus PATCH 5/8] maint: set the first minimal version that will be released

[Pavel Hrdina]

On Mon, Mar 19, 2018 at 02:16:15PM +0000, Daniel P. Berrangé wrote:
> On Mon, Mar 19, 2018 at 02:56:49PM +0100, Pavel Hrdina wrote:
> > On Mon, Mar 19, 2018 at 01:42:11PM +0000, Daniel P. Berrangé wrote:
> > > On Mon, Mar 19, 2018 at 10:30:49AM +0100, Pavel Hrdina wrote:
> > > > We will require libvirt to have at least the same version as
> > > > libvirt-dbus.  The 1.2.12 version is the lowest one which we will
> > > > support since it introduced virDomainDefineXMLFlags() and we don't
> > > > have to support the non-flags APIs.
> > > > 
> > > > Signed-off-by: Pavel Hrdina <phrdina at redhat.com>
> > > > ---
> > > >  configure.ac | 4 ++--
> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/configure.ac b/configure.ac
> > > > index df1a375..ba397ca 100644
> > > > --- a/configure.ac
> > > > +++ b/configure.ac
> > > > @@ -1,4 +1,4 @@
> > > > -AC_INIT([libvirt-dbus], [0.0.1], [libvir-list at redhat.com], [], [http://libvirt.org])
> > > > +AC_INIT([libvirt-dbus], [1.2.12], [libvir-list at redhat.com], [], [http://libvirt.org])
> > > >  
> > > >  AC_CONFIG_SRCDIR(src/main.c)
> > > >  AC_CONFIG_AUX_DIR([build-aux])
> > > > @@ -11,7 +11,7 @@ AC_USE_SYSTEM_EXTENSIONS
> > > >  
> > > >  AM_SILENT_RULES([yes])
> > > >  
> > > > -LIBVIRT_REQUIRED=1.2.8
> > > > +LIBVIRT_REQUIRED=AC_PACKAGE_VERSION
> > > 
> > > This feels a bit odd to me - what will you set the AC_INIT version to
> > > if you want todo 5 releases of libvirt-dbus, without bumping the min
> > > required version of libvirt.
> > > 
> > > I can understand having the libvirt-dbus versions be set in lockstep to
> > > libvirt versions in AC_INIT, if you plan to always do a libvirt-dbus
> > > release on the 1st of the month at same time as libvirt, but even then
> > > I doubt you'd want to set min required libvirt to match.
> > 
> > The reasoning behind it is that I would like to avoid using
> > #if LIBVIR_CHECK_VERSION() like we do in libvirt-python and strictly
> > depend on libvirt version that libvirt-dbus will be written for.
> 
> Wanting to avoid conditional version checks is a totally reasonable
> thing todo, so no objection to that. I'm just not sure it makes
> sense to tie the version numbers together unless you jump straight
> to the very latest version 4.2.0 right now and bump it again on
> each release.

That was my original idea to not tie the libvirt-dbus version numbers
together with libvirt.

Jumping straight to the latest version would mean more conservative
distribution would not be able to introduce libvirt-dbus unless they
bump libvirt itself or they adds downstream only patches to remove
non-existent APIs in the old libvirt.

That's why I changed my mind to follow libvirt versions and start
with some reasonably old version, implement all the libvirt APIs
till that version and make a release.  After that we would implement
remaining APIs based on the libvirt releases where new APIs was
introduced and match libvirt-dbus releases accordingly.

> > The other solution is to not use XML files for interface but have
> > the interface specified directly in the code in order to be able to
> > generate correct introspect data depending on what was compiled in.
> > 
> > Since this is more or less a binding, I think it would be better to
> > follow libvirt versions like we do with other bindings.
> > 
> > This was the first idea that I had and now I realize that it's not
> > good one.  I can change it back, however we need to make sure to
> > properly update the libvirt required version once we implement new
> > libvirt APIs.
> 
> You could write a 'make check' rule to validate this. eg run
> 
>   eu-readelf -a libvirt-dbus | grep LIBVIRT
> 
> this will give you all the ELF versions from libvirt that are
> used by libvirt-dbus. You can thus check if you've used a
> version that is newer than the value listed in configure.ac

Nice, TIL :).

Pavel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20180319/f9974c12/attachment-0001.sig>