From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: (release) versioning Date: Wed, 6 May 2015 01:15:25 +0200 Message-ID: <1430867725.5415.91.camel@citrix.com> References: <554903B90200007800076CFC@mail.emea.novell.com> <5548F848.2010701@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8700676807710270193==" Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Ypm4E-0006uv-Oh for xen-devel@lists.xenproject.org; Tue, 05 May 2015 23:15:58 +0000 In-Reply-To: <5548F848.2010701@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper Cc: xen-devel , Jan Beulich List-Id: xen-devel@lists.xenproject.org --===============8700676807710270193== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-VLaVk46jG/b6Yead/1QD" --=-VLaVk46jG/b6Yead/1QD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2015-05-05 at 18:05 +0100, Andrew Cooper wrote: > On 05/05/15 16:54, Jan Beulich wrote: > > All, > > > > on the hackathon we also discussed possibly changing the versioning > > of Xen. The main rationale for the proposal is that (just like in many > > other software projects) version numbers (in particular the major > > one) currently don't really convey much information. The proposal is > > to take gcc's new versioning scheme as a basis (i.e. I'm not going to > > claim that the below is an exact copy of theirs): Major releases > > always increment the major version number. Minor version 0 is > > reserved to the development cycle, i.e. the first release in any > > release series would be 5.1.0. RCs would be expressed through the > > 3rd digit, i.e. the first RC of the currently being worked on release > > would be 5.0.1 > I like this. > (there was some debate as to whether, despite > > being redundant, to attach -rc1 to it to make clear this is not an > > actual release). > > I see the point of making it clear enough that it's an RC, but then I don't like the redundancy. I.e., seeing something liek 5.0.1-rc1, 5.0.2-rc2, 5.0.3-rc3 would make me wonder what happened to 5.0.2-rc1, to 5.0.3-rc1 and -rc2 etc. > > So comparing current and new schemes things would go > > > > OLD NEW > > 4.6-unstable 5.0-unstable (or 5.0.0) > > 4.6.0-rc1 5.0.1 (-rc1) > > ... ... > > 4.6.0-rcN 5.0.N (-rcN) > > 4.6.0 5.1.0 > > 4.6.1-rc1 5.1.1 (-rc1) > > ... ... > > 4.6.1 5.2.0 > > It also feels a bit odd here, still if we keep the -rcX, that 5.0.N-rcN is the release candidate for 5.1.0... Wouldn't one then be the least surprised by just seeing the -rcN part dropped and 5.0.N be released? > > This additionally has the benefit that taking only the numeric > > part of the version string then would sort properly. > > > > Any comments or alternative proposals are welcome. >=20 Well, if we decide to keep the -rcX, then the 3rd digit will be: - always .0 for actual releases - always the same as -rc* for RCs so it looks to me that we can just kill it and have: 5.0-unstable 5.1-rc1 5.1-rc2 ... 5.1-rcN 5.1 5.2-rc1 ... 5.3 > +1 (relayed from the hackathon) >=20 All the above being said and FWIW, overall, +1 from me too. Regards, Dario --=-VLaVk46jG/b6Yead/1QD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEABECAAYFAlVJTw0ACgkQk4XaBE3IOsRTKQCggpHpNrlfnkgG4+8w5WfMFBXc m7YAnj2hYBZRE1jv53K0ik1StZ0H3sjM =4SqY -----END PGP SIGNATURE----- --=-VLaVk46jG/b6Yead/1QD-- --===============8700676807710270193== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8700676807710270193==--