[libvirt] [PATCH] build: commit to 0.10.0 release naming
With 0.10.0-rc0 out the door, we are committed to the next version number. * src/libvirt_public.syms (LIBVIRT_0.9.14): Rename... (LIBVIRT_0.10.0): ...to this. * docs/formatdomain.html.in: Fix fallout. * src/openvz/openvz_driver.c (openvzDriver): Likewise. * src/remote/remote_driver.c (remote_driver): Likewise. --- I almost pushed this under the trivial rule, but realized that anyone that builds an app against rc0 will be binary incompatible with the .so post-patch. Are we okay declaring that rc0 is unsupported so the ABI break is okay, or do I need to respin the .syms portion of this patch to keep the LIBVIRT_0.9.14 label even though we had no 0.9.14 release? docs/formatdomain.html.in | 2 +- src/libvirt_public.syms | 2 +- src/openvz/openvz_driver.c | 2 +- src/remote/remote_driver.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index b8db76e..54e0f13 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -780,7 +780,7 @@ CPU model will fail. Supported values for <code>fallback</code> attribute are: <code>allow</code> (this is the default), and <code>forbid</code>. The optional <code>vendor_id</code> attribute - (<span class="since">Since 0.9.14</span>) can be used to set the + (<span class="since">Since 0.10.0</span>) can be used to set the vendor id seen by the guest. It must be exactly 12 characters long. If not set the vendor id of the host is used. Typical possible values are "AuthenticAMD" and "GenuineIntel".</dd> diff --git a/src/libvirt_public.syms b/src/libvirt_public.syms index 5004182..e3ba119 100644 --- a/src/libvirt_public.syms +++ b/src/libvirt_public.syms @@ -544,7 +544,7 @@ LIBVIRT_0.9.13 { virDomainSnapshotRef; } LIBVIRT_0.9.11; -LIBVIRT_0.9.14 { +LIBVIRT_0.10.0 { global: virDomainGetHostname; virConnectRegisterCloseCallback; diff --git a/src/openvz/openvz_driver.c b/src/openvz/openvz_driver.c index 4cc7f46..48b5219 100644 --- a/src/openvz/openvz_driver.c +++ b/src/openvz/openvz_driver.c @@ -2170,7 +2170,7 @@ static virDriver openvzDriver = { .domainIsUpdated = openvzDomainIsUpdated, /* 0.8.6 */ .isAlive = openvzIsAlive, /* 0.9.8 */ .domainUpdateDeviceFlags = openvzDomainUpdateDeviceFlags, /* 0.9.13 */ - .domainGetHostname = openvzDomainGetHostname, /* 0.9.14 */ + .domainGetHostname = openvzDomainGetHostname, /* 0.10.0 */ }; int openvzRegister(void) { diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c index 9ac27b2..23b13d3 100644 --- a/src/remote/remote_driver.c +++ b/src/remote/remote_driver.c @@ -5378,7 +5378,7 @@ static virDriver remote_driver = { .domainGetDiskErrors = remoteDomainGetDiskErrors, /* 0.9.10 */ .domainSetMetadata = remoteDomainSetMetadata, /* 0.9.10 */ .domainGetMetadata = remoteDomainGetMetadata, /* 0.9.10 */ - .domainGetHostname = remoteDomainGetHostname, /* 0.9.14 */ + .domainGetHostname = remoteDomainGetHostname, /* 0.10.0 */ }; static virNetworkDriver network_driver = { -- 1.7.11.2
On Wed, Aug 01, 2012 at 11:00:35AM -0600, Eric Blake wrote:
With 0.10.0-rc0 out the door, we are committed to the next version number.
* src/libvirt_public.syms (LIBVIRT_0.9.14): Rename... (LIBVIRT_0.10.0): ...to this. * docs/formatdomain.html.in: Fix fallout. * src/openvz/openvz_driver.c (openvzDriver): Likewise. * src/remote/remote_driver.c (remote_driver): Likewise. ---
I almost pushed this under the trivial rule, but realized that anyone that builds an app against rc0 will be binary incompatible with the .so post-patch. Are we okay declaring that rc0 is unsupported so the ABI break is okay, or do I need to respin the .syms portion of this patch to keep the LIBVIRT_0.9.14 label even though we had no 0.9.14 release?
If rc1 won't be too far in the future (so it can be pushed into distros) just changing the symbol names is probably good enough. Cheers, -- Guido
docs/formatdomain.html.in | 2 +- src/libvirt_public.syms | 2 +- src/openvz/openvz_driver.c | 2 +- src/remote/remote_driver.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index b8db76e..54e0f13 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -780,7 +780,7 @@ CPU model will fail. Supported values for <code>fallback</code> attribute are: <code>allow</code> (this is the default), and <code>forbid</code>. The optional <code>vendor_id</code> attribute - (<span class="since">Since 0.9.14</span>) can be used to set the + (<span class="since">Since 0.10.0</span>) can be used to set the vendor id seen by the guest. It must be exactly 12 characters long. If not set the vendor id of the host is used. Typical possible values are "AuthenticAMD" and "GenuineIntel".</dd> diff --git a/src/libvirt_public.syms b/src/libvirt_public.syms index 5004182..e3ba119 100644 --- a/src/libvirt_public.syms +++ b/src/libvirt_public.syms @@ -544,7 +544,7 @@ LIBVIRT_0.9.13 { virDomainSnapshotRef; } LIBVIRT_0.9.11;
-LIBVIRT_0.9.14 { +LIBVIRT_0.10.0 { global: virDomainGetHostname; virConnectRegisterCloseCallback; diff --git a/src/openvz/openvz_driver.c b/src/openvz/openvz_driver.c index 4cc7f46..48b5219 100644 --- a/src/openvz/openvz_driver.c +++ b/src/openvz/openvz_driver.c @@ -2170,7 +2170,7 @@ static virDriver openvzDriver = { .domainIsUpdated = openvzDomainIsUpdated, /* 0.8.6 */ .isAlive = openvzIsAlive, /* 0.9.8 */ .domainUpdateDeviceFlags = openvzDomainUpdateDeviceFlags, /* 0.9.13 */ - .domainGetHostname = openvzDomainGetHostname, /* 0.9.14 */ + .domainGetHostname = openvzDomainGetHostname, /* 0.10.0 */ };
int openvzRegister(void) { diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c index 9ac27b2..23b13d3 100644 --- a/src/remote/remote_driver.c +++ b/src/remote/remote_driver.c @@ -5378,7 +5378,7 @@ static virDriver remote_driver = { .domainGetDiskErrors = remoteDomainGetDiskErrors, /* 0.9.10 */ .domainSetMetadata = remoteDomainSetMetadata, /* 0.9.10 */ .domainGetMetadata = remoteDomainGetMetadata, /* 0.9.10 */ - .domainGetHostname = remoteDomainGetHostname, /* 0.9.14 */ + .domainGetHostname = remoteDomainGetHostname, /* 0.10.0 */ };
static virNetworkDriver network_driver = { -- 1.7.11.2
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On 08/01/2012 01:18 PM, Guido Günther wrote:
On Wed, Aug 01, 2012 at 11:00:35AM -0600, Eric Blake wrote:
With 0.10.0-rc0 out the door, we are committed to the next version number.
* src/libvirt_public.syms (LIBVIRT_0.9.14): Rename... (LIBVIRT_0.10.0): ...to this. * docs/formatdomain.html.in: Fix fallout. * src/openvz/openvz_driver.c (openvzDriver): Likewise. * src/remote/remote_driver.c (remote_driver): Likewise. ---
I almost pushed this under the trivial rule, but realized that anyone that builds an app against rc0 will be binary incompatible with the .so post-patch. Are we okay declaring that rc0 is unsupported so the ABI break is okay, or do I need to respin the .syms portion of this patch to keep the LIBVIRT_0.9.14 label even though we had no 0.9.14 release?
If rc1 won't be too far in the future (so it can be pushed into distros) just changing the symbol names is probably good enough.
DV said that rc1 might be as much as 3 weeks away. If distros want to push rc0 out the door, and we decide to go with this patch as-is, then distros should backport this patch on top of rc0 for minimal pain. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On Wed, Aug 01, 2012 at 01:27:09PM -0600, Eric Blake wrote:
On 08/01/2012 01:18 PM, Guido Günther wrote:
On Wed, Aug 01, 2012 at 11:00:35AM -0600, Eric Blake wrote:
With 0.10.0-rc0 out the door, we are committed to the next version number.
* src/libvirt_public.syms (LIBVIRT_0.9.14): Rename... (LIBVIRT_0.10.0): ...to this. * docs/formatdomain.html.in: Fix fallout. * src/openvz/openvz_driver.c (openvzDriver): Likewise. * src/remote/remote_driver.c (remote_driver): Likewise. ---
I almost pushed this under the trivial rule, but realized that anyone that builds an app against rc0 will be binary incompatible with the .so post-patch. Are we okay declaring that rc0 is unsupported so the ABI break is okay, or do I need to respin the .syms portion of this patch to keep the LIBVIRT_0.9.14 label even though we had no 0.9.14 release?
If rc1 won't be too far in the future (so it can be pushed into distros) just changing the symbol names is probably good enough.
DV said that rc1 might be as much as 3 weeks away. If distros want to push rc0 out the door, and we decide to go with this patch as-is, then distros should backport this patch on top of rc0 for minimal pain.
yeah rc0 is not a release candidate, it's a snapshot, it's basically unsupported. It may not have compliled (it didn't in some configurations) it is a completely arbitrary upstream commit, like one of the ftp://libvirt.org/libvirt/libvirt-git-snapshot.tar.gz So your patch looks fine to me, i re-did it on my own too, so ACK Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On Thu, Aug 02, 2012 at 06:54:37PM +0800, Daniel Veillard wrote:
On Wed, Aug 01, 2012 at 01:27:09PM -0600, Eric Blake wrote:
On 08/01/2012 01:18 PM, Guido Günther wrote:
On Wed, Aug 01, 2012 at 11:00:35AM -0600, Eric Blake wrote:
With 0.10.0-rc0 out the door, we are committed to the next version number.
* src/libvirt_public.syms (LIBVIRT_0.9.14): Rename... (LIBVIRT_0.10.0): ...to this. * docs/formatdomain.html.in: Fix fallout. * src/openvz/openvz_driver.c (openvzDriver): Likewise. * src/remote/remote_driver.c (remote_driver): Likewise. ---
I almost pushed this under the trivial rule, but realized that anyone that builds an app against rc0 will be binary incompatible with the .so post-patch. Are we okay declaring that rc0 is unsupported so the ABI break is okay, or do I need to respin the .syms portion of this patch to keep the LIBVIRT_0.9.14 label even though we had no 0.9.14 release?
If rc1 won't be too far in the future (so it can be pushed into distros) just changing the symbol names is probably good enough.
DV said that rc1 might be as much as 3 weeks away. If distros want to push rc0 out the door, and we decide to go with this patch as-is, then distros should backport this patch on top of rc0 for minimal pain.
yeah rc0 is not a release candidate, it's a snapshot, it's basically unsupported. It may not have compliled (it didn't in some configurations) it is a completely arbitrary upstream commit, like one of the ftp://libvirt.org/libvirt/libvirt-git-snapshot.tar.gz
So your patch looks fine to me, i re-did it on my own too, so ACK
BTW I pushed yours since you gave more commit comments :-) Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
participants (3)
-
Daniel Veillard -
Eric Blake -
Guido Günther