ANNOUNCE: Xen 3.0.5 rename to 3.1.0

ANNOUNCE: Xen 3.0.5 rename to 3.1.0

[Keir Fraser]

Folks,

The imminent next Xen release introduces a host of important new features
including PV 32-on-64, HVM save/restore, and XenAPI 1.0. Now is a good time
to bump our version number and reclaim the redundant second digit!

We plan to rename the xen-3.0.5-testing.hg tree to xen-3.1.0-testing later
today. The release candidate will be renamed to 3.1.0-rc4. The final release
will be called 3.1.0 (as opposed to 3.0.5-0 in the old numbering scheme).
Further bug-fix releases in the 3.1 series will be called 3.1.x (as opposed
to 3.0.5-x in the old numbering scheme).

This change rationalises and simplifies our version numbering scheme. It
avoids the need for the fourth digit "-x", and incrementing the second
rather than third digit makes it clearer that large changes, not just bug
fixes, are incorporated in our quarterly major releases.

 Thanks,
 Keir

Re: ANNOUNCE: Xen 3.0.5 rename to 3.1.0

[Daniel P. Berrange]

On Wed, May 02, 2007 at 10:10:43AM +0100, Keir Fraser wrote:
> Folks,
> 
> The imminent next Xen release introduces a host of important new features
> including PV 32-on-64, HVM save/restore, and XenAPI 1.0. Now is a good time
> to bump our version number and reclaim the redundant second digit!
> 
> We plan to rename the xen-3.0.5-testing.hg tree to xen-3.1.0-testing later
> today. The release candidate will be renamed to 3.1.0-rc4. The final release
> will be called 3.1.0 (as opposed to 3.0.5-0 in the old numbering scheme).
> Further bug-fix releases in the 3.1 series will be called 3.1.x (as opposed
> to 3.0.5-x in the old numbering scheme).

Sounds like a good plan - makes it simpler to fit it in with RPM version
numbering too.

> This change rationalises and simplifies our version numbering scheme. It
> avoids the need for the fourth digit "-x", and incrementing the second
> rather than third digit makes it clearer that large changes, not just bug
> fixes, are incorporated in our quarterly major releases.

What is the relationship now between the hypervisor kernel capability
version numbers & the software release numbers ? I assume the HV ABI
versions should be considered to be decoupled now & they'll stay on
a value of 3.0 ? 

$ cat /sys/hypervisor/properties/capabilities 
xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

Re: ANNOUNCE: Xen 3.0.5 rename to 3.1.0

[Keir Fraser]

On 2/5/07 15:02, "Daniel P. Berrange" <berrange@redhat.com> wrote:

>> This change rationalises and simplifies our version numbering scheme. It
>> avoids the need for the fourth digit "-x", and incrementing the second
>> rather than third digit makes it clearer that large changes, not just bug
>> fixes, are incorporated in our quarterly major releases.
> 
> What is the relationship now between the hypervisor kernel capability
> version numbers & the software release numbers ? I assume the HV ABI
> versions should be considered to be decoupled now & they'll stay on
> a value of 3.0 ? 
> 
> $ cat /sys/hypervisor/properties/capabilities
> xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p

Yes. In an ideal world we would have used this version-numbering scheme in
the first place and made the capability identifiers xen-3-x86_32p etc. Never
mind.

 -- Keir

Re: ANNOUNCE: Xen 3.0.5 rename to 3.1.0

[Keir Fraser]

On 2/5/07 15:12, "Keir Fraser" <keir@xensource.com> wrote:

>> What is the relationship now between the hypervisor kernel capability
>> version numbers & the software release numbers ? I assume the HV ABI
>> versions should be considered to be decoupled now & they'll stay on
>> a value of 3.0 ?
>> 
>> $ cat /sys/hypervisor/properties/capabilities
>> xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p
> 
> Yes. In an ideal world we would have used this version-numbering scheme in
> the first place and made the capability identifiers xen-3-x86_32p etc. Never
> mind.

But that reminds me that the caps are generated dynamically from major/minor
inside Xen. Argh! I'd better fix that.

 -- Keir

Re: ANNOUNCE: Xen 3.0.5 rename to 3.1.0

[Cédric Schieli]

[-- Attachment #1.1: Type: text/plain, Size: 1114 bytes --]

Shouldn't the various library sonames (libblktap, libxenctrl, libxenguest,
libxutil, libxenstore) also be bumped to 3.1 ?

Regards,
Cédric


2007/5/2, Keir Fraser <keir@xensource.com>:
>
>
>
>
> On 2/5/07 15:12, "Keir Fraser" <keir@xensource.com> wrote:
>
> >> What is the relationship now between the hypervisor kernel capability
> >> version numbers & the software release numbers ? I assume the HV ABI
> >> versions should be considered to be decoupled now & they'll stay on
> >> a value of 3.0 ?
> >>
> >> $ cat /sys/hypervisor/properties/capabilities
> >> xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p
> >
> > Yes. In an ideal world we would have used this version-numbering scheme
> in
> > the first place and made the capability identifiers xen-3-x86_32p etc.
> Never
> > mind.
>
> But that reminds me that the caps are generated dynamically from
> major/minor
> inside Xen. Argh! I'd better fix that.
>
> -- Keir
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

[-- Attachment #1.2: Type: text/html, Size: 1599 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: ANNOUNCE: Xen 3.0.5 rename to 3.1.0

[Daniel P. Berrange]

On Wed, May 02, 2007 at 11:33:04PM +0200, C?dric Schieli wrote:
> Shouldn't the various library sonames (libblktap, libxenctrl, libxenguest,
> libxutil, libxenstore) also be bumped to 3.1 ?

Why ? Doing that would uneccessarily break any apps built against them.
As a general rule library so versions should not be artificially tied
to the software release number. A new software release does not imply
the library ABI has been changed - so versions should only be changed
when there is an actual ABI breakage to deal with.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

Re: ANNOUNCE: Xen 3.0.5 rename to 3.1.0

[Brendan Cully]

On Wednesday, 02 May 2007 at 22:38, Daniel P. Berrange wrote:
> On Wed, May 02, 2007 at 11:33:04PM +0200, C?dric Schieli wrote:
> > Shouldn't the various library sonames (libblktap, libxenctrl, libxenguest,
> > libxutil, libxenstore) also be bumped to 3.1 ?
> 
> Why ? Doing that would uneccessarily break any apps built against them.
> As a general rule library so versions should not be artificially tied
> to the software release number. A new software release does not imply
> the library ABI has been changed - so versions should only be changed
> when there is an actual ABI breakage to deal with.

Apps should only break if the major number changes. Bumping the minor
should be fairly harmless. It usually just indicates that the library
has new functions (but is backward-compatible with anything in the same
major with a smaller minor).

Re: ANNOUNCE: Xen 3.0.5 rename to 3.1.0

[Daniel P. Berrange]

On Wed, May 02, 2007 at 02:43:21PM -0700, Brendan Cully wrote:
> On Wednesday, 02 May 2007 at 22:38, Daniel P. Berrange wrote:
> > On Wed, May 02, 2007 at 11:33:04PM +0200, C?dric Schieli wrote:
> > > Shouldn't the various library sonames (libblktap, libxenctrl, libxenguest,
> > > libxutil, libxenstore) also be bumped to 3.1 ?
> > 
> > Why ? Doing that would uneccessarily break any apps built against them.
> > As a general rule library so versions should not be artificially tied
> > to the software release number. A new software release does not imply
> > the library ABI has been changed - so versions should only be changed
> > when there is an actual ABI breakage to deal with.
> 
> Apps should only break if the major number changes. Bumping the minor
> should be fairly harmless. It usually just indicates that the library
> has new functions (but is backward-compatible with anything in the same
> major with a smaller minor).

Agreed - the .so's are using 3 digits, the first two of which are used
by linker. So bumping 3.0.0  -> 3.0.1 would be fine, but the suggested
change of 3.0.0 -> 3.1.0 would break things.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

Re: ANNOUNCE: Xen 3.0.5 rename to 3.1.0

[Brendan Cully]

On Wednesday, 02 May 2007 at 22:53, Daniel P. Berrange wrote:
> On Wed, May 02, 2007 at 02:43:21PM -0700, Brendan Cully wrote:
> > On Wednesday, 02 May 2007 at 22:38, Daniel P. Berrange wrote:
> > > On Wed, May 02, 2007 at 11:33:04PM +0200, C?dric Schieli wrote:
> > > > Shouldn't the various library sonames (libblktap, libxenctrl, libxenguest,
> > > > libxutil, libxenstore) also be bumped to 3.1 ?
> > > 
> > > Why ? Doing that would uneccessarily break any apps built against them.
> > > As a general rule library so versions should not be artificially tied
> > > to the software release number. A new software release does not imply
> > > the library ABI has been changed - so versions should only be changed
> > > when there is an actual ABI breakage to deal with.
> > 
> > Apps should only break if the major number changes. Bumping the minor
> > should be fairly harmless. It usually just indicates that the library
> > has new functions (but is backward-compatible with anything in the same
> > major with a smaller minor).
> 
> Agreed - the .so's are using 3 digits, the first two of which are used
> by linker. So bumping 3.0.0  -> 3.0.1 would be fine, but the suggested
> change of 3.0.0 -> 3.1.0 would break things.

Sorry, hadn't noticed the linker was using the first two digits.

Re: ANNOUNCE: Xen 3.0.5 rename to 3.1.0

[Jun Koi]

On 5/2/07, Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote:
> Folks,
>
> The imminent next Xen release introduces a host of important new features
> including PV 32-on-64, HVM save/restore, and XenAPI 1.0. Now is a good time
> to bump our version number and reclaim the redundant second digit!
>
> We plan to rename the xen-3.0.5-testing.hg tree to xen-3.1.0-testing later
> today. The release candidate will be renamed to 3.1.0-rc4. The final release
> will be called 3.1.0 (as opposed to 3.0.5-0 in the old numbering scheme).
> Further bug-fix releases in the 3.1 series will be called 3.1.x (as opposed
> to 3.0.5-x in the old numbering scheme).
>
> This change rationalises and simplifies our version numbering scheme. It
> avoids the need for the fourth digit "-x", and incrementing the second
> rather than third digit makes it clearer that large changes, not just bug
> fixes, are incorporated in our quarterly major releases.
>

I think it is a good idea to update information at
http://www.cl.cam.ac.uk/research/srg/netos/xen/downloads.html, because
many people still look at it first. It is quite outdated now.

Thanks,
Jun