[Spice-devel] Release 0.11.0

Submitted by Alon Levy on June 7, 2012, 11:12 a.m.

Details

Message ID 1339067542-32285-1-git-send-email-alevy@redhat.com
State New
Headers show

Not browsing as part of any series.

Commit Message

Alon Levy June 7, 2012, 11:12 a.m.
---
 NEWS         |   27 +++++++++++++++++++++++++++
 configure.ac |    4 ++--
 2 files changed, 29 insertions(+), 2 deletions(-)

Patch hide | download patch | download mbox

diff --git a/NEWS b/NEWS
index 2deba57..5201bcb 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,30 @@ 
+Major changes in 0.11.0:
+* !Development Release!
+* 8817549..d905a1f
+* now using git submodules: spice-common and spice-protocol.
+* New spice protocol messages: (changes in spice-protocol, here for reference)
+ * SPICE_MSG_MAIN_NAME, SPICE_MSG_MAIN_UUID
+ * SPICE_MSG_DISPLAY_STREAM_DATA_SIZED
+* New corresponding caps: (changes in spice-protocol, here for reference)
+ * SPICE_MAIN_CAP_NAME_AND_UUID
+ * SPICE_DISPLAY_CAP_SIZED_STREAM.
+* Send name & uuid to capable clients
+* add support for frames of different sizes rhbz #813826
+* server:
+ * support a pre-opened file descriptor
+ * Solaris support. Now using poll instead of epoll.
+ * Support IPV6 addresses in channel events RHBZ #788444
+ * other fixed rhbz#: 787669, 787678, 819484
+* spicec
+ * alsa: use "default" instead of "hw:0,0"
+ * volume keys support RHBZ #552539
+ * other fixed rhbz#: 78655, 804561, 641828
+* solaris, mingw & windows, 32 bit fixes.
+* enable server only build.
+* GNULIB manywarnings.m4 & warnings.m4 module added.
+* Many more bug fixes & code cleanups.
+* spice-protocol no longer external.
+
 Major changes in 0.10.1:
 ========================
 * Mini header support
diff --git a/configure.ac b/configure.ac
index 66f9d12..4f95c0e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,8 +1,8 @@ 
 AC_PREREQ([2.57])
 
 m4_define([SPICE_MAJOR], 0)
-m4_define([SPICE_MINOR], 10)
-m4_define([SPICE_MICRO], 1)
+m4_define([SPICE_MINOR], 11)
+m4_define([SPICE_MICRO], 0)
 
 AC_INIT(spice, [SPICE_MAJOR.SPICE_MINOR.SPICE_MICRO], [], spice)
 

Comments

On Thu, Jun 7, 2012 at 1:12 PM, Alon Levy <alevy@redhat.com> wrote:
> ---
>  NEWS         |   27 +++++++++++++++++++++++++++
>  configure.ac |    4 ++--
>  2 files changed, 29 insertions(+), 2 deletions(-)

Looks good to me, although I wonder why we never bump
SPICE_LT_VERSION. In theory we should
http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html.
Perhaps we should bump to 1, 0, 3.
On Thu, Jun 07, 2012 at 03:35:00PM +0200, Marc-André Lureau wrote:
> On Thu, Jun 7, 2012 at 1:12 PM, Alon Levy <alevy@redhat.com> wrote:
> > ---
> >  NEWS         |   27 +++++++++++++++++++++++++++
> >  configure.ac |    4 ++--
> >  2 files changed, 29 insertions(+), 2 deletions(-)
> 
> Looks good to me, although I wonder why we never bump
> SPICE_LT_VERSION. In theory we should
> http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html.
> Perhaps we should bump to 1, 0, 3.

I agree that we need to change it, but I find that page very confusing.
According to point 2 at the bottom, since we are backward compatible but
added interfaces, we should increment both ''current'' and ''age'', i.e.
2.0.3

According to the set of rules (bullets 1-6) at the top, we should
increment ''revision'' (per point 3, since the source code changed) and
increment ''age'' per rule 5, i.e. 1.1.3

If I take the intersection of those two I get what you proposed (which
makes sense, but I can't reach it following that page..)

> 
> -- 
> Marc-André Lureau
Hi

----- Mensaje original -----

> I agree that we need to change it, but I find that page very
> confusing.
> According to point 2 at the bottom, since we are backward compatible
> but
> added interfaces, we should increment both ''current'' and ''age'',
> i.e.
> 2.0.3

This is the correct way. I was blindly following Gerd
reasoning from b718f59d4617067c589dae020d14bf4327e2fa62, which appears
to be invalid, since bumping age always should go with current.

This is also stated differently in the documentation:
"Also note that age must be less than or equal to the current interface number"

I don't know how we can fix it :-/
On Sat, Jun 09, 2012 at 06:16:25PM -0400, Marc-André Lureau wrote:
> Hi
> 
> ----- Mensaje original -----
> 
> > I agree that we need to change it, but I find that page very
> > confusing.
> > According to point 2 at the bottom, since we are backward compatible
> > but
> > added interfaces, we should increment both ''current'' and ''age'',
> > i.e.
> > 2.0.3
> 
> This is the correct way. I was blindly following Gerd
> reasoning from b718f59d4617067c589dae020d14bf4327e2fa62, which appears
> to be invalid, since bumping age always should go with current.
> 
> This is also stated differently in the documentation:
> "Also note that age must be less than or equal to the current interface number"
> 
> I don't know how we can fix it :-/

3.0.3?

I'll reread the page in the morning.