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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Daniel P. Berrange
2007-May-02 14:02 UTC
Re: [Xen-devel] ANNOUNCE: Xen 3.0.5 rename to 3.1.0
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 -=| _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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_32pYes. 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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
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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Daniel P. Berrange
2007-May-02 21:38 UTC
Re: [Xen-devel] ANNOUNCE: Xen 3.0.5 rename to 3.1.0
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 -=| _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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). _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Daniel P. Berrange
2007-May-02 21:53 UTC
Re: [Xen-devel] ANNOUNCE: Xen 3.0.5 rename to 3.1.0
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 -=| _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel