From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: (release) versioning Date: Tue, 05 May 2015 16:54:01 +0100 Message-ID: <554903B90200007800076CFC@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YpfAa-0003aG-Nd for xen-devel@lists.xenproject.org; Tue, 05 May 2015 15:54:04 +0000 Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel List-Id: xen-devel@lists.xenproject.org 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 (there was some debate as to whether, despite being redundant, to attach -rc1 to it to make clear this is not an actual release). 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 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. Regards, Jan